wehub/cloudflare--workers-sdk
1
0
Fork 0
Code Issues Pull Requests Actions 1 Deployments Models Agent Notes Packages Projects Releases Wiki Activity
Files
main
cloudflare--workers-sdk/packages/vite-plugin-cloudflare/CHANGELOG.md
T
wehub-resource-sync 70bf21e064
Deploy (to testing) and Test Playground Preview Worker / Deploy Playground Preview Worker (testing) (push) Has been skipped
Details
Deploy Workers Shared Staging / Deploy Workers Shared Staging (push) Failing after 0s
Details
Prerelease / build (push) Has been skipped
Details
Handle Changesets / Handle Changesets (push) Has been cancelled
Details
Semgrep OSS scan / semgrep-oss (push) Has been cancelled
Details
chore: import upstream snapshot with attribution
2026-07-13 12:30:11 +08:00

285 KiB
Raw Permalink Blame History

@cloudflare/vite-plugin

1.44.0

Minor Changes

  • #14535 1b965c5 Thanks @Naapperas! - Support dynamic retry delays for Workflow steps in local dev

    A step's retries.delay can now be a function that computes the delay per failed attempt, in addition to a static duration. The function receives { ctx, error } and returns a delay (a number of milliseconds or a duration string like "30 seconds"), and its result is fed into the configured backoff.

    await step.do(
  "call flaky API",
  {
    retries: {
      limit: 5,
      backoff: "constant",
      delay: ({ ctx }) => ctx.attempt * 1000,
    },
  },
  async () => {
    /* ... */
  }
);

    The function is invoked once per failed attempt with a 5 second timeout. If it throws, times out, or returns an invalid value, the step fails without further retries.

Patch Changes

1.43.3

Patch Changes

1.43.2

Patch Changes

1.43.1

Patch Changes

1.43.0

Minor Changes

  • #14382 fd92d56 Thanks @petebacondarwin! - Add support for declarative Durable Object exports

    wrangler deploy now accepts an exports map in wrangler.json as a declarative alternative to the legacy migrations array.

    Each entry in exports is keyed by Durable Object class name. type carries the export kind (currently always "durable-object"); the state field carries the lifecycle and defaults to "created" (live) when omitted:

    {
  "exports": {
    // Provision a new Durable Object class (`MyDO`)
    "MyDO": { "type": "durable-object", "storage": "sqlite" },
    // Delete Durable Object class (`OldGone`)
    "OldGone": { "type": "durable-object", "state": "deleted" },
    // Rename a Durable Object class (from `OldName` to `NewName`)
    "OldName": {
      "type": "durable-object",
      "state": "renamed",
      "renamed_to": "NewName"
    },
    "NewName": { "type": "durable-object", "storage": "sqlite" },
    // Transfer a Durable Object (`Outgoing`) to a new Worker (`target-worker`)
    "Outgoing": {
      "type": "durable-object",
      "state": "transferred",
      "transferred_to": "target-worker"
    },
    // Prepare to receive the transfer of a Durable Object (`Incoming`) from another Worker (`source-worker`)
    "Incoming": {
      "type": "durable-object",
      "state": "expecting-transfer",
      "storage": "sqlite",
      "transfer_from": "source-worker"
    }
  }
}

    When a Worker declares Durable Object class bindings but no lifecycle for them (neither a migrations array nor an exports map), wrangler warns and now suggests a declarative exports entry for each class (previously it suggested a legacy migrations block).

    The deployment response now surfaces the server's reconciliation result — created namespaces, applied tombstones, structured per-scenario info entries, and a removable_entries hint for stale tombstones that are safe to delete from the config. Blocking errors return the structured per-class detail with scenario tags, suggested remediation, and any referencing-script context.

    wrangler versions upload also forwards exports. Declarative exports lifecycle changes are reconciled when the version is deployed (wrangler versions deploy or wrangler deploy), so a versions upload payload can declare new classes in exports without immediately provisioning them. An actor binding (durable_objects.bindings) to a class declared only in exports on the same versions upload is rejected with a clear error (code 100406) — the binding cannot be resolved until the namespace is provisioned. Either stage the new class via ctx.exports.X (no binding required) on versions upload and add the binding at deploy time, or use wrangler deploy to provision and bind in one step (the same constraint applies to the migrations flow).

    Multi-version deploys (wrangler versions deploy A@50% B@50%) where the selected versions disagree on declarative exports are rejected server-side with a clear message: deploy the version that changes exports at 100% first, then run the percentage-split deploy. This prevents traffic on one branch routing to code that references unprovisioned or just-deleted DO namespaces. Single-version (100%) deploys are unaffected.

    Local development (wrangler dev, vite dev and unstable_startWorker) reads Durable Object SQLite storage settings from the new exports field, so applications using the declarative flow get correct local-dev storage without needing to also declare a migrations block.

    @cloudflare/vitest-pool-workers also picks up Durable Object configuration from exports, so tests against an exports-only Worker run with the correct local SQLite storage and can reach unbound Durable Object classes via ctx.exports.X.

    wrangler types is also aware of exports. Live entries (including expecting-transfer, the receiving side of a two-phase transfer) are added to Cloudflare.GlobalProps.durableNamespaces, which types ctx.exports.X for unbound Durable Objects declared only via exports.

Patch Changes

1.42.4

Patch Changes

1.42.3

Patch Changes

1.42.2

Patch Changes

1.42.1

Patch Changes

  • #14366 c6579d3 Thanks @jamesopstad! - Resolve relative cf-worker entrypoint imports relative to the importing module

    When loading the experimental cloudflare.config.ts, a relative entrypoint imported with import ... with { type: "cf-worker" } (e.g. ./src/index.ts) is now anchored to the module where the import is written, rather than being passed through verbatim and later resolved against the top-level config file. This fixes incorrect resolution when the import lives in a file other than the entry config — for example a config that re-exports from a nested file.

    Bare specifiers (such as @scope/pkg) and virtual modules (such as virtual:foo) are still left unresolved so that consumers can apply their own resolution.

  • Updated dependencies [c6579d3, 444b75e, b38823f, cfd6205, cfd6205]:

1.42.0

Minor Changes

  • #14339 aa49856 Thanks @jamesopstad! - Add a build command to the experimental, internal cf-vite delegate binary

    cf-vite build runs Vite's full multi-environment app build (via the Builder API) and enables the experimental Build Output API by default, emitting a self-contained .cloudflare/output/v0/ directory. It forces experimental.newConfig and experimental.newConfig.cfBuildOutput on, so a cloudflare.config.ts is required at the project root.

Patch Changes

  • #14346 e930bd4 Thanks @haidargit! - Bump ws from 8.20.1 to 8.21.0 to address GHSA-96hv-2xvq-fx4p

    GHSA-96hv-2xvq-fx4p / CVE-2026-48779 (high severity) reports a remote memory-exhaustion DoS in ws@<8.21.0: a peer sending a high volume of tiny fragments and data chunks over modest network traffic can crash a ws server or client via OOM. The fix shipped in ws@8.21.0 (commit 2b2abd45, released 2026-05-22), which also introduces the maxBufferedChunks and maxFragments options. This change bumps the workspace catalog entry so that miniflare, wrangler, and @cloudflare/vite-plugin all pick up the patched release.

  • #14351 6c7df19 Thanks @jamesopstad! - Force the experimental new config on by default in the cf-vite dev delegate

  • #14218 4eed569 Thanks @matingathani! - Allow resolve.external containing only Node.js built-ins in Worker environments

    Vitest 4 automatically sets resolve.external to the full list of Node.js built-in modules for non-standard Vite environments via its internal runnerTransform plugin. Previously, the Cloudflare Vite plugin rejected any non-empty resolve.external array, throwing an incompatibility error on startup when used alongside Vitest 4.

    The validation check now allows resolve.external arrays that contain only Node.js built-in module names (both bare fs and node:fs forms). The error is only thrown when resolve.external is true or contains non-built-in package names that would prevent user code from being bundled into the Worker.

  • Updated dependencies [673b09e, e930bd4, f6e49dd, 5c3bb11, 296ad65, 594544d, a79b899, 5dfb788, ca61558, 36777db]:

1.41.0

Minor Changes

  • #14279 e6e4b07 Thanks @jamesopstad! - Add experimental.newConfig.cfBuildOutput option to support future deployments via the cf CLI

    // vite.config.ts
import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({
      experimental: {
        newConfig: {
          cfBuildOutput: true,
        },
      },
    }),
  ],
});

Patch Changes

1.40.2

Patch Changes

1.40.1

Patch Changes

1.40.0

Minor Changes

  • #14013 3cf9d0e Thanks @jamesopstad! - Add experimental experimental.newConfig option to load the entry Worker's configuration from cloudflare.config.ts

    This is an experimental, opt-in feature. When enabled, the plugin loads the entry Worker's configuration from a cloudflare.config.ts file instead of the usual wrangler.json / wrangler.jsonc / wrangler.toml.

    Pass true to enable with defaults, or an object to customise behaviour. Currently the only sub-option is types.generate (defaults to true), which writes a worker-configuration.d.ts file next to the config. This enables typed env and exports for your Worker and currently assumes that you have @cloudflare/workers-types installed.

    // vite.config.ts
import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({
      experimental: {
        newConfig: true,
      },
    }),
  ],
});

    // cloudflare.config.ts
import {
	defineWorker,
	bindings,
} from "@cloudflare/vite-plugin/experimental-config";
import * as entrypoint from "./src/index.ts" with { type: "cf-worker" };

export default defineWorker((ctx) => ({
	name: "my-worker",
	entrypoint,
	compatibilityDate: "2026-05-18",
	env: {
		MY_TEXT: bindings.text(`The mode is ${ctx.mode}`),
		MY_KV: bindings.kv(),
	},
}));

    A few limitations apply while the feature is experimental:

    • configPath cannot be combined with experimental.newConfig. The entry Worker is always loaded from cloudflare.config.ts at the project root.
    • auxiliaryWorkers are not yet supported with experimental.newConfig.

    Because this is experimental, the option, the cloudflare.config.ts schema, and the @cloudflare/vite-plugin/experimental-config exports may change in any release.

Patch Changes

1.39.2

Patch Changes

  • #13893 d8a16e7 Thanks @penalosa! - Add an experimental, internal cf-vite delegate binary

    This adds an experimental bin/cf-vite binary that is spawned by Cloudflare's own parent tooling to drive the plugin as a long-running dev-server subprocess. It is not part of the plugin's public API surface, is not intended to be invoked directly, and its contract may change at any time without notice.

  • #14117 3c86121 Thanks @aicayzer! - Forward response headers from the Worker on WebSocket upgrade responses

    Headers set on a new Response(null, { status: 101, webSocket, headers }) returned from the Worker are now propagated to the upgrade response sent to the browser during vite dev. Previously the headers were dropped, so cookies (Set-Cookie) and custom headers (X-*) on WebSocket handshake responses were invisible client-side — even though they were delivered correctly by wrangler dev.

  • Updated dependencies [b210c5e, aec1bb8, e06cbb7, 9a26191, 5565823, 4ef790b, 890fca7, 6fc9777, 337e912, 8e7b74f, e86489a, 42288d4, 65b5f9e, 3a746ac, 64ef9fd, 94b29f7]:

1.39.1

Patch Changes

1.39.0

Minor Changes

  • #13985 c809d30 Thanks @jamesopstad! - Add assetsOnly (entry Worker) and devOnly (auxiliary Workers) options to the plugin config

    Both options accept a boolean or a function that returns a boolean. The function is evaluated lazily at build time, allowing frameworks to provide the value after initialization.

    Use assetsOnly on the entry Worker to skip building the Worker and instead emit an assets-only Wrangler config to the client output directory. This enables frameworks such as Astro to use the ssr environment during development but produce a fully static app for deployment.

    export default defineConfig({
  plugins: [
    cloudflare({
      assetsOnly: () => isStaticBuild,
    }),
  ],
});

    Use devOnly on an auxiliary Worker to include it during vite dev but skip it at build time.

    export default defineConfig({
  plugins: [
    cloudflare({
      auxiliaryWorkers: [
        { configPath: "./dev-only-worker/wrangler.jsonc", devOnly: true },
      ],
    }),
  ],
});

Patch Changes

1.38.0

Minor Changes

  • #13989 f598eac Thanks @MattieTK! - Print a QR code alongside the tunnel URL when sharing via Cloudflare Tunnel

    When a tunnel is started (via wrangler dev --tunnel or the Vite plugin with tunnel: true), a scannable QR code is now printed to the terminal beneath the tunnel URL. This makes it easy to open the tunnel on a mobile device without manually copying the URL.

    The QR code uses Unicode block characters for a compact representation and is generated best-effort -- if generation fails for any reason, the tunnel URL is still displayed as before.

Patch Changes

1.37.3

Patch Changes

  • #13978 fa1f61f Thanks @sassyconsultingllc! - Bump ws from 8.18.0 to 8.20.1 to address GHSA-58qx-3vcg-4xpx

    GHSA-58qx-3vcg-4xpx / CVE-2026-45736 reports an uninitialized-memory disclosure in ws@<8.20.1 when a TypedArray is passed as the reason argument to WebSocket.close(). The fix shipped in ws@8.20.1 on 2026-05-12. This change bumps the workspace catalog entry so that miniflare, wrangler, and @cloudflare/vite-plugin all pick up the patched release.

  • #13912 d803737 Thanks @petebacondarwin! - Fix /cdn-cgi/* host validation incorrectly accepting subdomains of exact configured routes

    Miniflare's /cdn-cgi/* host/origin validator was treating exact configured routes the same as wildcard configured routes, so a request whose Host or Origin hostname was a subdomain of an exact route (e.g. sub.my-custom-site.com for a my-custom-site.com/* route) was incorrectly accepted. Exact configured routes and the configured upstream hostname are now required to match the request hostname exactly. Subdomain matching is only applied to wildcard routes such as *.example.com/*. Localhost hostnames continue to be allowed as before.

    This affects wrangler dev and local development through @cloudflare/vite-plugin, both of which use Miniflare under the hood.

  • #13919 c7eab7f Thanks @petebacondarwin! - Fix the outbound CF-Worker header reflecting the route pattern hostname instead of the parent zone, and falling back to <worker-name>.example.com under vite dev, vitest-pool-workers, and getPlatformProxy

    Two related issues affected the CF-Worker header on outbound subrequests in local development:

    1. Under @cloudflare/vite-plugin, @cloudflare/vitest-pool-workers, and getPlatformProxy, the header fell back to <worker-name>.example.com even when routes were configured, because unstable_getMiniflareWorkerOptions and the equivalent getPlatformProxy worker-options path did not propagate a zone value to Miniflare. This broke local development against services that reject unknown CF-Worker hosts (for example, Apple WeatherKit returns 403 Forbidden).
    2. Across the above paths and wrangler dev --local, when a route used the zone_name field (for example { pattern: "foo.example.com/*", zone_name: "example.com" }), the header was set to the pattern's hostname (foo.example.com) rather than the zone name (example.com). Production sets CF-Worker to the zone name that owns the Worker, so this was inconsistent with deployed behaviour.

    Both bugs are fixed: the new unstable_getMiniflareWorkerOptions / getPlatformProxy path now propagates a zone derived from the first configured route, and all four local-dev paths now prefer a route's explicit zone_name over the pattern hostname when computing that zone. When zone_name isn't set, the existing best-effort behaviour is preserved — for wrangler dev this means dev.host is still honoured as a local override and the pattern hostname is used as a final fallback. Resolving the parent zone for zone_id-only, custom_domain, or plain-string routes would require an API lookup, so locally we still approximate it with the pattern hostname.

    Note: dev.host is intentionally not consulted by the unstable_getMiniflareWorkerOptions / getPlatformProxy paths — the dev config block is specific to wrangler dev.

  • Updated dependencies [fa1f61f, 2679e05, 7e40d98, adc9221, 735852d, d803737, c7eab7f, e04e180, 59cd880, 62abf97, e8c2031, e349fe0, da0fa8c, a5c9365]:

1.37.2

Patch Changes

1.37.1

Patch Changes

  • #13922 23800f8 Thanks @edmundhung! - Add a tunnel shortcut hint when CLI shortcuts are printed

    The Cloudflare Vite plugin now includes a t + enter tunnel hint alongside the other CLI shortcuts it prints.

  • #13920 f579e57 Thanks @petebacondarwin! - Honor X-Forwarded-Proto when constructing the Worker's request.url

    When running the Vite dev server behind a TLS-terminating reverse proxy or tunnel, the Worker's request.url was always http://... even though the client reached the server over https://.... This caused frameworks that perform Origin/Host checks (e.g. CSRF protection) to reject requests with 403.

    The Vite plugin now reads the X-Forwarded-Proto header from the incoming request and uses it to set the protocol of request.url. If the header is absent or invalid, the connection protocol is used as before. The same handling is applied to WebSocket upgrade URLs.

    Fixes #13801.

  • Updated dependencies [19ed49a, 3ff0a50, bf688f7, 2e72c83, 802eaf4, 506aa02, 8f5cdb1, be8a98c]:

1.37.0

Minor Changes

  • #13903 7ce6f6f Thanks @edmundhung! - Add named tunnel support to the cloudflare() Vite plugin

    You can now expose your local dev server publicly with a stable hostname by configuring tunnel with a named Cloudflare Tunnel:

    cloudflare({
  tunnel: { name: "my-tunnel", autoStart: true },
});

    If autoStart is omitted or set to false, you can still start or close the tunnel by pressing t + enter.

Patch Changes

1.36.4

Patch Changes

1.36.3

Patch Changes

1.36.2

Patch Changes

1.36.1

Patch Changes

  • #13802 a7fd465 Thanks @deodad! - Fix .dev.vars written for vite preview to round-trip values containing quotes

    When the plugin emits dist/<env>/.dev.vars for vite preview, it previously wrote each value as a double-quoted dotenv string with " escaped to \". dotenv (the parser wrangler uses) does not unescape \" inside double-quoted values, so values containing " arrived at the worker with literal backslashes still in them.

    The plugin now quotes strings using the first quote character that does not appear in the value (with the priority order: single → backtick → double), all of which dotenv strips correctly. If a value contains every supported quote character it throws instead of silently corrupting the value.

  • Updated dependencies [2284f20, 332f527, 039bada, 18e833d, b6cea17, 1a54ac5, 53e846a, f3fed88, beff19c, af42fed, 1a54ac5]:

1.36.0

Minor Changes

  • #13810 2b8c0cc Thanks @jamesopstad! - Stabilize the secrets configuration property

    The secrets property in the Wrangler config file is no longer experimental and will no longer emit an experimental warning when used. Required secrets are validated during local development and deploy, and used as the source of truth for type generation.

    {
  "secrets": {
    "required": ["API_KEY", "DB_PASSWORD"]
  }
}

Patch Changes

1.35.0

Minor Changes

  • #13618 c07d0cb Thanks @jamesopstad! - Support V2 protocol for module fallback service

    When the new_module_registry compatibility flag is set, requests sent to unsafeModuleFallbackService() use a different protocol. The Vite plugin now supports both protocols in its handling of additional module types.

Patch Changes

1.34.0

Minor Changes

  • #13666 edcff69 Thanks @edmundhung! - Add tunnel: true to the cloudflare() Vite plugin for sharing your local dev and preview servers via Cloudflare Quick Tunnels

    You can now expose your local dev server publicly by setting tunnel: true:

    cloudflare({
  tunnel: true,
});

    You can also enable tunnel sharing dynamically using an environment variable:

    cloudflare({
  tunnel: process.env.ENABLE_DEV_TUNNEL === "true",
});

    This starts a Cloudflare Quick Tunnel that gives you a random *.trycloudflare.com URL to share. The tunnel stops automatically when the dev or preview session ends. Quick tunnels don't require a Cloudflare account or any configuration.

    A warning is shown when Server-Sent Events (SSE) responses are detected through the tunnel, since quick tunnels don't support SSE.

Patch Changes

1.33.2

Patch Changes

  • #13636 1d54fb7 Thanks @edmundhung! - Stop denying vite.config.* files from Vite dev server access

    This allows projects to access vite.config.* files during development when needed.

  • #13653 48c61b6 Thanks @jamesopstad! - Use the date that the plugin is built as the default compatibility date.

    When no compatibility date was set by the user, the plugin was falling back to the current date. This meant that the date could get ahead of the latest date supported by the installed version of workerd. We now populate the default compatibility date when the plugin is built. This means that it is updated with each release but then stays fixed.

  • #13634 f3cb2b2 Thanks @jamesopstad! - Simplify /cdn-cgi/ handling

    We now only add special handling for /cdn-cgi/handler/* routes, so that trigger handlers are invoked on the User Worker.

  • #13611 6e99feb Thanks @smaldd14! - Support Cloudflare-managed registry images in Vite plugin local dev

    Previously, using a registry.cloudflare.com image in a containers binding would crash vite dev with an unsupported error. The Vite plugin now configures the Cloudflare API client using CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID before pulling container images, matching the behavior of wrangler dev.

  • Updated dependencies [5a2968a, 5680287, 3494842, 7d728fb, df9319d, d5e3c57, 3ceeec3, 7567ef7, 0a95061, 2831b54, 7fc50c1, 377715d]:

1.33.1

Patch Changes

1.33.0

Minor Changes

  • #12600 50bf819 Thanks @penalosa! - Use workerd's debug port to power cross-process service bindings, Durable Objects, and tail workers via the dev registry. This enables Durable Object RPC via the dev registry, and is an overall stability improvement.

Patch Changes

1.32.3

Patch Changes

1.32.2

Patch Changes

1.32.1

Patch Changes

1.32.0

Minor Changes

  • #13137 1313275 Thanks @emily-shen! - Add e hotkey to open local explorer during dev

    Press e during vite dev to open the local explorer UI at /cdn-cgi/explorer, which allows you to inspect the state of your D1, R2, KV, DO and Workflow bindings.

Patch Changes

1.31.2

Patch Changes

1.31.1

Patch Changes

1.31.0

Minor Changes

  • #13011 b9b7e9d Thanks @ruifigueira! - Add experimental headful browser rendering support for local development

    Experimental: This feature may be removed or changed without notice.

    When developing locally with the Browser Rendering API, you can enable headful (visible) mode via the X_BROWSER_HEADFUL environment variable to see the browser while debugging:

    X_BROWSER_HEADFUL=true wrangler dev
X_BROWSER_HEADFUL=true vite dev

    Note: when using @cloudflare/playwright, two Chrome windows may appear — the initial blank page and the one created by browser.newPage(). This is expected behavior due to how Playwright handles browser contexts via CDP.

  • #13051 d5bffde Thanks @dario-piotrowicz! - Update getLocalWorkerdCompatibilityDate to return today's date

    The re-exported getLocalWorkerdCompatibilityDate function from @cloudflare/vite-plugin previously resolved the workerd compatibility date by traversing the local miniflare installation, which was unreliable in some package manager setups. It now simply returns today's date. The function is also marked as deprecated — callers should just use today's date instead, for example like so: new Date().toISOString().slice(0, 10)

Patch Changes

1.30.3

Patch Changes

1.30.2

Patch Changes

1.30.1

Patch Changes

1.30.0

Minor Changes

  • #12848 ce48b77 Thanks @emily-shen! - Enable local explorer by default

    This ungates the local explorer, a UI that lets you inspect the state of D1, DO and KV resources locally by visiting /cdn-cgi/explorer during local development.

    Note: this feature is still experimental, and can be disabled by setting the env var X_LOCAL_EXPLORER=false.

Patch Changes

1.29.1

Patch Changes

  • #12936 cff91ff Thanks @jamesopstad! - Select the appropriate vite/module-runner implementation during dev based on the user's Vite version

    The plugin now builds against Vite 8 and ships two bundled copies of vite/module-runner: one from Vite 8 and one from Vite 7.1.12 (the last version before a breaking change to the module runner in Vite 7.2.0). At dev server startup, the correct implementation is selected based on the user's installed Vite version. This is Vite 8's module runner for users on Vite >= 7.2.0, and the legacy module runner for users on older versions.

  • Updated dependencies [c9b3184, 13df6c7, df0d112, 81ee98e, c600ce0, f509d13, 3b81fc6, 0a7fef9]:

1.29.0

Minor Changes

  • #12885 12505c9 Thanks @edmundhung! - Add Vite 8 to the supported peer dependency range

    The package now lists Vite 8 in its peer dependency range, so installs with Vite 8 no longer show a peer dependency warning.

Patch Changes

  • #12859 876108a Thanks @dario-piotrowicz! - Fix crash when plugins send HMR events before runner initialization

    Previously, if another Vite plugin (such as vite-plugin-vue-devtools) sent HMR events during configureServer before the Cloudflare plugin had initialized its runner, the dev server would crash with AssertionError: The WebSocket is undefined. The environment's WebSocket send operations are now deferred until the runner is fully initialized, allowing early HMR events to be handled gracefully.

  • Updated dependencies [ade0aed, 2b9a186, 65f1092, 7b0d8f5, 351e1e1, 2b9a186]:

1.28.0

Minor Changes

  • #12855 c2b76bc Thanks @jamesopstad! - Support local explorer /cdn-cgi/ routes

    The local explorer UI can now be accessed at /cdn-cgi/explorer.

Patch Changes

  • #12834 64edac7 Thanks @jamesopstad! - Warn when the assets field is provided for auxiliary Workers

    Auxiliary Workers do not support static assets. Previously, the assets field was silently ignored but we now warn if it is used.

  • #12794 b980af6 Thanks @aron-cf! - Fix Sandbox SDK preview URL WebSocket routing

    When using Sandbox SDK preview URLs, WebSocket requests using the vite-hmr protocol could be dropped before they reached the worker, causing HMR to fail. The plugin now forwards Sandbox WebSocket traffic and preserves the original request origin/host so worker proxy logic receives the correct URL.

  • Updated dependencies [f7de0fd, ff543e3, 8e89e85, e63539d, 8d1e130, 6ee18e1, ecc7f79, 1dda1c8, 4bb61b9]:

1.27.0

Minor Changes

  • #12826 de65c58 Thanks @gabivlj! - Enable container egress interception in local dev without the experimental compatibility flag

    Container local development now always prepares the egress interceptor sidecar image needed for interceptOutboundHttp(). This makes container-to-Worker interception available by default in Wrangler, Miniflare, and the Cloudflare Vite plugin.

Patch Changes

1.26.1

Patch Changes

1.26.0

Minor Changes

  • #12649 35b2c56 Thanks @gabivlj! - Add experimental support for containers to workers communication with interceptOutboundHttp

    This feature is experimental and requires adding the "experimental" compatibility flag to your Wrangler configuration.

  • #12701 23a365a Thanks @jamesopstad! - Add local dev validation for the experimental secrets configuration property

    When the new secrets property is defined, wrangler dev and vite dev now validate secrets declared in secrets.required. When required secrets are missing from .dev.vars or .env/process.env, a warning is logged listing the missing secret names.

    When secrets is defined, only the keys listed in secrets.required are loaded. Additional keys in .dev.vars or .env are excluded. If you are not using .dev.vars, keys listed in secrets.required are loaded from process.env as well as .env. The CLOUDFLARE_INCLUDE_PROCESS_ENV environment variable is therefore not needed when using this feature.

    When secrets is not defined, the existing behavior is unchanged.

    // wrangler.jsonc
{
  "secrets": {
    "required": ["API_KEY", "DB_PASSWORD"]
  }
}

Patch Changes

1.25.6

Patch Changes

1.25.5

Patch Changes

  • #12628 494ee7b Thanks @Master-Hash! - Append Cloudflare defaults to existing .assetsignore files during build output

    When a project includes a PUBLIC_DIR/.assetsignore, the plugin now preserves those rules and appends the required wrangler.json and .dev.vars entries instead of replacing the file content.

  • Updated dependencies [3d6e421, 294297e]:

1.25.4

Patch Changes

1.25.3

Patch Changes

1.25.2

Patch Changes

1.25.1

Patch Changes

1.25.0

Minor Changes

  • #12535 bd06ad2 Thanks @edmundhung! - Set { serverHandler: false } automatically when using @vitejs/plugin-rsc

    By default, @vitejs/plugin-rsc adds dev and preview server middleware that imports the RSC entry in Node.js. This fails with cloudflare:* imports (ERR_UNSUPPORTED_ESM_URL_SCHEME) and is unnecessary since the Cloudflare plugin handles requests via workerd. Users no longer need to pass rsc({ serverHandler: false }) manually.

Patch Changes

1.24.0

Minor Changes

  • #12446 1231a2e Thanks @jamesopstad! - Infer upload_source_maps setting in the output Worker config from the build.sourcemap setting in the Vite config.

    If build.sourcemap is enabled for a Worker environment, as in the following example, "upload_source_maps": true will now automatically be added to the output wrangler.json file. This removes the need to additionally specify the upload_source_maps property in the input Worker config.

    export default defineConfig({
  environments: {
    my_worker: {
      build: {
        sourcemap: true,
      },
    },
  },
  plugins: [cloudflare()],
});

    Note that if upload_source_maps is set in the input Worker config, this value will take precedence. This makes it possible to generate source maps without uploading them.

Patch Changes

1.23.1

Patch Changes

  • #12381 98283fa Thanks @jamesopstad! - Avoid collecting nodejs_compat warnings during dependency optimization.

    Previously, a custom plugin was provided during dependency optimization to collect warnings when Node.js built-ins were imported and the nodejs_compat flag was not enabled. Because optimized dependencies are cached, the warning was only displayed when dependencies changed. Additionally, it sometimes included false positives from dependencies that were no longer used. We now always externalize Node.js built-ins during dependency optimization and collect the warnings at runtime. This is more consistent with how warnings are collected for direct imports of Node.js built-ins.

  • Updated dependencies [ee9b81f, 63f1adb, ba13de9, 447daa3, fe3af35, bd4bb98, dab4bc9, 83adb2c, 18c0784]:

1.23.0

Minor Changes

  • #11697 67a4ab1 Thanks @jamesopstad! - Add experimental.prerenderWorker option to the plugin config.

    This enables configuring a dedicated Worker for prerendering at build time. This is an experimental feature and may change or be removed at any time.

  • #12214 4db3864 Thanks @jamesopstad! - Use Hook Filters to optimize plugin performance with Vite 8. This skips unnecessary Rust-to-JS calls with Rolldown powered Vite.

Patch Changes

1.22.1

Patch Changes

1.22.0

Minor Changes

  • #12034 05714f8 Thanks @emily-shen! - Add a no-op local explorer worker, which is gated by the experimental flag X_LOCAL_EXPLORER.

Patch Changes

1.21.2

Patch Changes

1.21.1

Patch Changes

1.21.0

Minor Changes

  • #11879 5c8ff05 Thanks @jamesopstad! - Add support for child environments.

    This is to support React Server Components via @vitejs/plugin-rsc and frameworks that build on top of it. A childEnvironments option is now added to the plugin config to enable using multiple environments within a single Worker. The parent environment can import modules from a child environment in order to access a separate module graph. For a typical RSC use case, the plugin might be configured as in the following example:

    export default defineConfig({
  plugins: [
    cloudflare({
      viteEnvironment: {
        name: "rsc",
        childEnvironments: ["ssr"],
      },
    }),
  ],
});

Patch Changes

  • #11898 c17e971 Thanks @petebacondarwin! - Bundle more third-party dependencies to reduce supply chain risk

    Previously, several small utility packages were listed as runtime dependencies and installed separately. These are now bundled directly into the published packages, reducing the number of external dependencies users need to trust.

    Bundled dependencies:

    • miniflare: acorn, acorn-walk, exit-hook, glob-to-regexp, stoppable
    • kv-asset-handler: mime
    • vite-plugin-cloudflare: @remix-run/node-fetch-server, defu, get-port, picocolors, tinyglobby
    • vitest-pool-workers: birpc, devalue, get-port, semver

  • Updated dependencies [e78186d, fe4faa3, fec8f5b, d39777f, 4714ca1, c17e971, 695b043]:

1.20.3

Patch Changes

1.20.2

Patch Changes

1.20.1

Patch Changes

1.20.0

Minor Changes

  • #11620 25f6672 Thanks @dario-piotrowicz! - Expose a new getLocalWorkerdCompatibilityDate utility that allows callers to get the compatibility date of the locally installed workerd package.

  • #11723 3455912 Thanks @jamesopstad! - Add a post buildApp hook that builds Worker environments that haven't already been built.

    This ensures that auxiliary Workers are included in the build when using full-stack frameworks that define their own builder.buildApp function. Note that this feature is not supported with Vite 6 as the buildApp hook was introduced in Vite 7.

  • #11738 c54f8da Thanks @jamesopstad! - Add default Text module rule for .sql files.

    This enables importing .sql files directly in Wrangler and the Cloudflare Vite plugin without extra configuration.

Patch Changes

1.19.0

Minor Changes

  • #11670 3483b84 Thanks @jamesopstad! - Provide the resolved entry Worker config in the second parameter to the auxiliary Worker config function. This makes it straightforward to inherit configuration from the entry Worker in auxiliary Workers.

    Example:

    export default defineConfig({
  plugins: [
    cloudflare({
      auxiliaryWorkers: [
        {
          config: (_, { entryWorkerConfig }) => ({
            name: "auxiliary-worker",
            main: "./src/auxiliary-worker.ts",
            // Inherit compatibility settings from entry Worker
            compatibility_date: entryWorkerConfig.compatibility_date,
            compatibility_flags: entryWorkerConfig.compatibility_flags,
          }),
        },
      ],
    }),
  ],
});

Patch Changes

1.18.0

Minor Changes

  • #11045 12a63ef Thanks @edmundhung! - Add keyboard shortcut to display Worker bindings during development

    When running vite dev or vite preview, you can now press b + Enter to display a list of all bindings configured for your Worker(s). This makes it easier to discover and verify which resources (e.g. KV namespaces, Durable Objects, environment variables, etc.) are available to your Worker during development.

    This feature requires vite version 7.2.7 or later.

  • #11265 06f48c0 Thanks @petebacondarwin! - Add a check to vite-plugin that ensures that the version of Wrangler being used internally is correct

    In some pnpm setups it is possible for a different peer dependency version of Wrangler to leak and override the version that we require internally.

Patch Changes

1.17.1

Patch Changes

1.17.0

Minor Changes

Patch Changes

1.16.1

Patch Changes

1.16.0

Minor Changes

  • #11445 c8e22c3 Thanks @ascorbic! - Allow Worker config to be customized in the plugin config

    The Vite plugin can now be used to generate a Worker configuration instead of needing a Wrangler config file, or to customize an existing user-provided configuration.

    This is done via a new config option on the plugin, which accepts either a partial Worker configuration object, or a function that receives the current configuration and returns a partial config object, or modifies the current config in place.

    import cloudflare from "@cloudflare/vite-plugin";
import { defineConfig } from "vite";

// Define a partial config object

export default defineConfig({
  plugins: [
    cloudflare({
      config: {
        compatibility_date: "2025-01-01",
      },
    }),
  ],
});

// Return a partial config from a function, conditional on some logic

export default defineConfig({
  plugins: [
    cloudflare({
      config: (workerConfig) => {
        if (workerConfig.name === "my-worker") {
          return {
            compatibility_flags: ["nodejs_compat"],
          };
        }
      },
    }),
  ],
});

// Modify the config in place

export default defineConfig({
  plugins: [
    cloudflare({
      config: (workerConfig) => {
        workerConfig.compatibility_date = "2025-01-01";
      },
    }),
  ],
});

  • #11360 6b38532 Thanks @emily-shen! - Containers: Allow users to directly authenticate external image registries in local dev

    Previously, we always queried the API for stored registry credentials and used those to pull images. This means that if you are using an external registry (ECR, dockerhub) then you have to configure registry credentials remotely before running local dev.

    Now you can directly authenticate with your external registry provider (using docker login etc.), and Wrangler or Vite will be able to pull the image specified in the containers.image field in your config file.

    The Cloudflare-managed registry (registry.cloudflare.com) currently still does not work with the Vite plugin.

  • #11408 f29e699 Thanks @ascorbic! - Support zero-config operation

    If the Vite plugin is used in a project without an existing Wrangler config file, it should be able to operate in "zero-config" mode by generating a default Wrangler configuration for an assets-only worker.

  • #11417 2ca70b1 Thanks @jamesopstad! - Register named entrypoints with the dev registry.

    This enables binding to named entrypoints defined in a vite dev session from another vite dev or wrangler dev session running locally.

Patch Changes

1.15.3

Patch Changes

1.15.2

Patch Changes

1.15.1

Patch Changes

1.15.0

Minor Changes

Patch Changes

1.14.2

Patch Changes

1.14.1

Patch Changes

1.14.0

Minor Changes

Patch Changes

1.13.19

Patch Changes

1.13.18

Patch Changes

1.13.17

Patch Changes

1.13.16

Patch Changes

1.13.15

Patch Changes

1.13.14

Patch Changes

1.13.13

Patch Changes

1.13.12

Patch Changes

1.13.11

Patch Changes

1.13.10

Patch Changes

1.13.9

Patch Changes

1.13.8

Patch Changes

1.13.7

Patch Changes

1.13.6

Patch Changes

1.13.5

Patch Changes

1.13.4

Patch Changes

1.13.3

Patch Changes

1.13.2

Patch Changes

1.13.1

Patch Changes

1.13.0

Minor Changes

  • #10212 0837a8d Thanks @jamesopstad! - Support packages and virtual modules in the main field of the Worker config. The primary use case is to enable users to directly provide a file exported by a framework as the Worker entry module.

  • #10604 135e066 Thanks @penalosa! - Enable Remote Bindings without the need for the experimental: { remoteBindings: true } property

Patch Changes

1.12.4

Patch Changes

1.12.3

Patch Changes

1.12.2

Patch Changes

1.12.1

Patch Changes

1.12.0

Minor Changes

Patch Changes

1.11.7

Patch Changes

1.11.6

Patch Changes

1.11.5

Patch Changes

1.11.4

Patch Changes

1.11.3

Patch Changes

1.11.2

Patch Changes

1.11.1

Patch Changes

1.11.0

Minor Changes

  • #9914 a24c9d8 Thanks @petebacondarwin! - Add support for loading local dev vars from .env files

    If there are no .dev.vars or .dev.vars.<environment> files, when running Wrangler or the Vite plugin in local development mode, they will now try to load additional local dev vars from .env, .env.local, .env.<environment> and .env.<environment>.local files.

    These loaded vars are only for local development and have no effect in production to the vars in a deployed Worker. Wrangler and Vite will continue to load .env files in order to configure themselves as a tool.

    Further details:

    • In vite build the local vars will be computed and stored in a .dev.vars file next to the compiled Worker code, so that vite preview can use them.
    • The wrangler types command will similarly read the .env files (if no .dev.vars files) in order to generate the Env interface.
    • If the CLOUDFLARE_LOAD_DEV_VARS_FROM_DOT_ENV environment variable is "false" then local dev variables will not be loaded from .env files.
    • If the CLOUDFLARE_INCLUDE_PROCESS_ENV environment variable is "true" then all the environment variables found on process.env will be included as local dev vars.
    • Wrangler (but not Vite plugin) also now supports the --env-file=<path/to/dotenv/file> global CLI option. This affects both loading .env to configure Wrangler the tool as well as loading local dev vars.

Patch Changes

1.10.2

Patch Changes

  • #10048 dbdbb8c Thanks @vicb! - pass the compatibility date and flags to the unenv preset

  • #10096 687655f Thanks @vicb! - bump unenv to 2.0.0-rc.19

  • #10040 26ffa05 Thanks @CarmenPopoviciu! - feat(vite-plugin): Add containers support in vite preview

    Adds support for Cloudflare Containers in vite preview. Please note that at the time of this PR a container image can only specify the path to a Dockerfile. Support for registry links will be added in a later version.

  • #10054 bc910f9 Thanks @eltigerchino! - Add worker to the default conditions for resolving packages

    This makes it consistent with the conditions used when bundling Worker code with Wrangler.

  • #10061 f8a80a8 Thanks @emily-shen! - fix: properly set the socket path that the container engine is listening on.

    Previously, this was only picking up the value set in Wrangler config under dev.containerEngine, but this value can also be set from env vars or automatically read from the current docker context.

  • Updated dependencies [82a5b2e, f8f7352, 2df1d06, f8a80a8, dbdbb8c, 5991a9c, 687655f, 755a249]:

1.10.1

Patch Changes

1.10.0

Minor Changes

  • #10001 5796ca9 Thanks @jamesopstad! - We now automatically inject the following HMR code into your Worker entry file:

    if (import.meta.hot) {
  import.meta.hot.accept();
}

    This prevents file changes from invalidating the full module graph and improves HMR performance in development.

Patch Changes

  • #10038 a355327 Thanks @emily-shen! - Resolve containers.image (if it is a path to a Dockerfile) to an absolute path in the deploy config.

  • #9891 dd416e9 Thanks @hi-ogawa! - set build.rollupOptions.platform: "neutral" on rolldown-vite to prevent Rolldown's node:module based require polyfill from breaking the build.

  • #9819 0c4008c Thanks @CarmenPopoviciu! - feat(vite-plugin): Add containers support in vite dev

    Adds support for Cloudflare Containers in vite dev. Please note that at the time of this PR a container image can only specify the path to a Dockerfile. Support for registry links will be added in a later version, as will containers support in vite preview.

  • Updated dependencies [189fe23, c02b067, 7e5585d, b0217f9, e87198a, ad02ad3, 0c4008c]:

1.9.6

Patch Changes

1.9.5

Patch Changes

1.9.4

Patch Changes

1.9.3

Patch Changes

1.9.2

Patch Changes

1.9.1

Patch Changes

1.9.0

Minor Changes

  • #9535 56dc5c4 Thanks @penalosa! - In 2023 we announced breakpoint debugging support for Workers, which meant that you could easily debug your Worker code in Wrangler's built-in devtools (accessible via the [d] hotkey) as well as multiple other devtools clients, including VSCode. For most developers, breakpoint debugging via VSCode is the most natural flow, but until now it's required manually configuring a launch.json file, running wrangler dev, and connecting via VSCode's built-in debugger.

    Now, using VSCode's built-in JavaScript Debug Terminals, there are just two steps: open a JS debug terminal and run vite dev or vite preview. VSCode will automatically connect to your running Worker (even if you're running multiple Workers at once!) and start a debugging session.

  • #9803 df04528 Thanks @penalosa! - Support Workers Analytics Engine & Rate Limiting bindings

Patch Changes

1.8.0

Minor Changes

  • #9773 45e97e8 Thanks @jamesopstad! - Vite 7 is now supported and included as a peer dependency. We continue to also support Vite 6.

  • #9753 67130b3 Thanks @jamesopstad! - Allow optimizeDeps.exclude to be specified for Worker environments. This enables other plugins to exclude dependencies from optimization that require access to virtual modules. Note that excluded dependencies must be ESM.

1.7.5

Patch Changes

1.7.4

Patch Changes

1.7.3

Patch Changes

1.7.2

Patch Changes

1.7.1

Patch Changes

1.7.0

Minor Changes

  • #9575 5601fc3 Thanks @jamesopstad! - Support run_worker_first.

    run_worker_first has been expanded to accept an array of routes that should go directly to your Worker. Additionally, routes can be omitted by adding a ! prefix. These negative routes will be treated as assets.

    This is a new way to define routing explicitly and, when provided, overrides the implicit routing behavior.

    {
  "assets": {
    "not_found_handling": "single-page-application",
    "run_worker_first": [
      "/api/*", // These routes go directly to the Worker
      "!/api/docs/*" // These routes are still treated as assets
    ]
  }
}

    The previous behavior of setting "run_worker_first": true to always invoke your Worker is also now supported.

Patch Changes

1.6.0

Minor Changes

  • #9510 590d69b Thanks @jamesopstad! - Enhanced build support for Workers with assets.

    Assets that are imported in the entry Worker are now automatically moved to the client build output. This enables importing assets in your Worker and accessing them via the assets binding. See Static Asset Handling to find out about all the ways you can import assets in Vite.

    Additionally, a broader range of build scenarios are now supported. These are:

    • Assets only build with client entry/entries
    • Assets only build with no client entry/entries that includes public directory assets
    • Worker(s) + assets build with client entry/entries
    • Worker(s) + assets build with no client entry/entries that includes imported and/or public directory assets
    • Worker(s) build with no assets

Patch Changes

1.5.1

Patch Changes

1.5.0

Minor Changes

  • #9341 2cef3ab Thanks @jamesopstad! - Support loading all asset types via assets binding. Previously only HTML assets could be loaded via the assets binding. The binding now integrates with Vite's internal middleware to load all asset types.

Patch Changes

1.4.0

Minor Changes

  • #9173 fac2f9d Thanks @edmundhung! - Enable cross-process Service bindings and Tail workers with the Dev Registry

    You can now run workers in separate dev sessions—whether vite dev or wrangler dev—and they’ll automatically discover and connect to each other:

    Worker A

    // ./worker-a/wrangler.jsonc
{
  "name": "worker-a",
  "main": "./src/index.ts",
  "services": [
    {
      "binding": "SERVICE",
      "service": "worker-b"
    }
  ]
}

    Worker B

    // ./worker-b/wrangler.jsonc
{
  "name": "worker-b",
  "main": "./src/index.ts",
  "tail_consumers": [
    {
      "service": "worker-a"
    }
  ]
}

    Then run both workers in separate terminals:

    # Terminal 1
cd worker-a
vite dev

# Terminal 2
cd worker-b
vite dev
# or `wrangler dev` if you prefer

    That's it!

Patch Changes

1.3.1

Patch Changes

  • #9387 e39a45f Thanks @jamesopstad! - Prevent leaking Miniflare server logs. Logs that were previously filtered were leaking as they were changed to include colors. We now override the new Miniflare Log.logReady method with a noop rather than filtering the logs.

  • #9308 d3a6eb3 Thanks @dario-piotrowicz! - Add new mixedMode experimental option

    Add a new mixedMode experimental option that allows uses to have their worker access remote resources during development (and preview)

    To enabled mixed mode set the corresponding option to the cloudflare plugin instantiation:

    export default defineConfig({
  plugins: [
    cloudflare({
      // ...
      experimental: { mixedMode: true },
    }),
  ],
});

    Thereafter bindings configured with the remote flags will be accessible by workers' code when run via vite dev and vite preview

  • Updated dependencies [34b6174, d9d937a, e39a45f, d3a6eb3, b8f058c, fdae3f7]:

1.3.0

Minor Changes

  • #9330 34c71ce Thanks @edmundhung! - Updated internal configuration to use Miniflare’s new defaultPersistRoot instead of per-plugin persist flags

Patch Changes

1.2.4

Patch Changes

1.2.3

Patch Changes

1.2.2

Patch Changes

1.2.1

Patch Changes

1.2.0

Minor Changes

  • #9152 dca4163 Thanks @jamesopstad! - Support HTTPS and HTTP/2. Configuring server.https and/or preview.https in your Vite config now works as expected. This was previously broken because Undici would add a transfer-encoding header for streamed responses. We now remove this header if the request uses HTTP/2.

Patch Changes

1.1.1

Patch Changes

1.1.0

Minor Changes

  • #9108 bb41346 Thanks @jamesopstad! - Add support for running Vite in middleware mode. This enables using Storybook with the Vite plugin, which would previously crash. WebSocket connections to Workers are not supported when in middleware mode.

Patch Changes

1.0.13

Patch Changes

1.0.12

Patch Changes

1.0.11

Patch Changes

1.0.10

Patch Changes

1.0.9

Patch Changes

1.0.8

Patch Changes

1.0.7

Patch Changes

1.0.6

Patch Changes

1.0.5

Patch Changes

1.0.4

Patch Changes

  • #8862 f843447 Thanks @jamesopstad! - Fix a bug where Node.js externals (i.e. Node.js imports that are included in the runtime) were being registered as missing imports with the depsOptimizer. This was previously causing the dev server to crash if these imports were encountered when using React Router.

1.0.3

Patch Changes

1.0.2

Patch Changes

  • #8823 f566680 Thanks @dario-piotrowicz! - fix: replace process.env.NODE_ENV for nodejs_compat builds

    make sure that occurrences of process.env.NODE_ENV are replaced with the current process.env.NODE_ENV value or "production" on builds that include the nodejs_compat flag, this enables libraries checking such value (e.g. react-dom) to be properly treeshaken

  • Updated dependencies [afd93b9, 930ebb2, 09464a6, 62df08a]:

1.0.1

Patch Changes

1.0.0

Major Changes

Patch Changes

0.1.21

Patch Changes

0.1.20

Patch Changes

  • #8688 28522ae Thanks @petebacondarwin! - Ensure that Node.js polyfills are pre-optimized before the first request

    Previously, these polyfills were only optimized on demand when Vite became aware of them. This was either because Vite was able to find an import to a polyfill when statically analysing the import tree of the entry-point, or when a polyfilled module was dynamically imported as part of a executing code to handle a request.

    In the second case, the optimizing of the dynamically imported dependency causes a reload of the Vite server, which can break applications that are holding state in modules during the request. This is the case of most React type frameworks, in particular React Router.

    Now, we pre-optimize all the possible Node.js polyfills when the server starts before the first request is handled.

  • #8680 8dcc50f Thanks @dario-piotrowicz! - fix: make sure that users can specify inspector port 0 to use a random port

  • #8572 e6fea13 Thanks @dario-piotrowicz! - Add validation for the configPath option in the plugin config that clearly indicates any issues.

  • #8672 d533f5e Thanks @dario-piotrowicz! - replace modules runtime checks with vite environment config validation

    currently at runtime the vite plugin applies checks to make sure that external files are not being imported, such checks are however too restrictive and prevent worker code to perform some valid imports from node_modules (e.g. import stylesheet from "<some-package>/styles.css?url";)

    the changes here replace the runtime checks (allowing valid imports from node_modules) with some validation to the worker vite environment configurations, specifically they make sure that the environment doesn't specify invalid optimizeDeps.exclude and resolve.external options

  • #8680 8dcc50f Thanks @dario-piotrowicz! - fix: make sure that the plugin keeps looking for available inspector ports by default

    this change updates the plugin so that if an inspector port is not specified and the default inspector port (9229) is not available it keeps looking for other available port instead of crashing

  • Updated dependencies [3993374, 8df60b5, ec1f813, 624882e]:

    • wrangler@4.7.0
    • @cloudflare/unenv-preset@2.3.1

0.1.19

Patch Changes

  • #8706 25eaf3b Thanks @jamesopstad! - Set the x-forwarded-host header to the original host in requests. This fixes a bug where libraries such as Clerk would redirect to the workerd host rather than the Vite host.

  • Updated dependencies [ecbab5d, 24c2c8f]:

    • wrangler@4.6.0
    • @cloudflare/unenv-preset@2.3.1

0.1.18

Patch Changes

0.1.17

Patch Changes

  • #8652 a18155f Thanks @jamesopstad! - Fix a bug where updating config files would crash the dev server. This occurred because the previous Miniflare instance was not disposed before creating a new one. This would lead to a port collision because of the inspectorPort introduced by the new debugging features.

  • Updated dependencies [8e3688f, f043b74, 14602d9]:

    • wrangler@4.5.0
    • @cloudflare/unenv-preset@2.3.1

0.1.16

Patch Changes

  • #8432 d611caf Thanks @GregBrimble! - Experimental: add support for Workers Assets metafiles (_headers and _redirects) in vite dev.

    Experimental feature: This feature is being made available behind an experimental option (headersAndRedirectsDevModeSupport) in the cloudflare plugin configuration. It could change or be removed at any time.

    cloudflare({
	// ...
	experimental: { headersAndRedirectsDevModeSupport: true },
}),

    Currently, in this experimental mode, requests that would result in an HTML response or a 404 response will take into account the _headers and _redirects settings.

    Known limitation: requests for existing static assets will be served directly by Vite without considering the _headers or _redirects settings.

    Production deployments or using vite preview already accurately supports the _headers and _footers features. The recommendation is to use vite preview for local testing of these settings.

  • Updated dependencies [7682675, 9c844f7, d8c0495, 29cb306, e4b76e8]:

0.1.15

Patch Changes

0.1.14

Patch Changes

0.1.13

Patch Changes

0.1.12

Patch Changes

0.1.11

Patch Changes

0.1.10

Patch Changes

0.1.9

Patch Changes

0.1.8

Patch Changes

  • #8320 c8fab4d Thanks @threepointone! - chore: tweak a couple of error messages in the vite plugin

    I was seeing an error like this: Unexpected error: no match for module path.. But it wasn't telling me what the path was. On debugging I noticed that it was telling me about the module "path"! Which meant I needed to enable node_compat. This patch just makes the messaging a little clearer.

    (Ideally we'd spot that it was a node builtin and recommend turning on node_compat, but I'll leave that to you folks.)

  • Updated dependencies [fce642d, ff96a70, a4909cb]:

0.1.7

Patch Changes

  • #8206 477f8d9 Thanks @jamesopstad! - Add support for binding to named entrypoints in the same worker

  • #8266 9f05e8f Thanks @jamesopstad! - Make it possible to override builder.buildApp in the user config or prior plugins

  • Updated dependencies []:

    • @cloudflare/unenv-preset@1.1.2

0.1.6

Patch Changes

0.1.5

Patch Changes

  • #8231 51a2fd3 Thanks @petebacondarwin! - fix: use ESM WebSocketServer import to avoid crashing vite dev

    It appears that if there are multiple versions of the ws package in a user's project then the Node.js resolution picks up the ESM "import" package export rather than the "require" package export. This results in the entry-point having different JS exports: In particular the default export no longer contains a Server property; instead one must import the WebSocketServer named JS export. While it is not clear why the Node.js behaviour changes in this way, the cleanest fix is to import the WebSocketServer directly.

0.1.4

Patch Changes

  • #8209 1427535 Thanks @jamesopstad! - Fix bug with usage of Cloudflare builtins in dependencies. These are now externalized during dependency optimization.

  • Updated dependencies []:

    • @cloudflare/unenv-preset@1.1.2

0.1.3

Patch Changes

  • #8176 693d63e Thanks @petebacondarwin! - fix: refactor Node.js compat support to ensure all polyfills are pre-bundled before the first request

0.1.2

Patch Changes

0.1.1

Patch Changes

  • #8118 ca3cbc4 Thanks @petebacondarwin! - fix Node.js compat module resolution

    In v0.0.8 we landed support for Vite 6.1 and also switched to using the new Cloudflare owned unenv preset. Unfortunately, the changes made in that update caused a regression in Node.js support. This became apparent only when the plugin was being used with certain package managers and outside of the workers-sdk monorepo.

    The unenv polyfills that get compiled into the Worker are transitive dependencies of this plugin, not direct dependencies of the user's application were the plugin is being used. This is on purpose to avoid the user having to install these dependencies themselves.

    Unfortunately, the changes in 0.0.8 did not correctly resolve the polyfills from @cloudflare/unenv-preset and unenv when the dependencies were not also installed directly into the user's application.

    The approach was incorrectly relying upon setting the importer in calls to Vite's resolve(id, importer) method to base the resolution in the context of the vite plugin package rather than the user's application. This doesn't work because the importer is only relevant when the id is relative, and not a bare module specifier in the case of the unenv polyfills.

    This change fixes how these id are resolved in the plugin by manually resolving the path at the appropriate point, while still leveraging Vite's resolution pipeline to handle aliasing, and dependency optimization.

    This change now introduces e2e tests that checks that isolated installations of the plugin works with npm, pnpm and yarn.

  • Updated dependencies [28b1dc7]:

0.1.0

Minor Changes

  • #8080 d0fda3d Thanks @jamesopstad! - No longer call next in server middleware.

    This is so that the Cloudflare plugin can override subsequent dev middleware for framework integrations.

Patch Changes

0.0.8

Patch Changes

0.0.7

Patch Changes

0.0.6

Patch Changes

0.0.5

Patch Changes

0.0.4

Patch Changes

0.0.3

Patch Changes

0.0.2

Patch Changes

0.0.1

Patch Changes

Reference in New Issue View Git Blame Copy Permalink