chore(deps): update dependency @cloudflare/vite-plugin to v1.44.0

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@cloudflare/vite-plugin (source)	1.31.0 → 1.44.0

---

Release Notes

cloudflare/workers-sdk (@​cloudflare/vite-plugin)

v1.44.0

Compare Source

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

• Updated dependencies [0283a1f, 7b28392, 1b965c5]:
  • wrangler@​4.110.0
  • miniflare@​4.20260708.1

v1.43.3

Compare Source

Patch Changes

• Updated dependencies [e3f0cd6, 8511ddf, 9f74a5f, e3f0cd6, c782e2a, 2fedb1f, 17d2fc1]:
  • miniflare@​4.20260708.0
  • wrangler@​4.109.0

v1.43.2

Compare Source

Patch Changes

• Updated dependencies [54f74b8, 0852346, 54f74b8]:
  • wrangler@​4.108.0
  • miniflare@​4.20260706.0

v1.43.1

Compare Source

Patch Changes

• Updated dependencies [e7e5780, d88555e, 5fd8bee, 5d9990e, bf49a41, 1ac96a1, f416dd9, 1ca8d8f, 16fbf81, b973ed3]:
  • miniflare@​4.20260702.0
  • wrangler@​4.107.1

v1.43.0

Compare Source

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

• Updated dependencies [aa5d580, 6b0ce98, fd92d56, bfe48db, be3f792, 0277bfa, 98793d8, e1532eb]:
  • wrangler@​4.107.0
  • miniflare@​4.20260701.0

v1.42.4

Compare Source

Patch Changes

• #​14490 75d8cb0 Thanks @​petebacondarwin! - Preserve D1 migration paths in generated Worker configs

  When a Worker config with a D1 binding is built by the Vite plugin, the generated wrangler.json now points migrations_dir back to the source migration directory. This lets tools that read the generated config, such as createTestHarness(), find the same D1 migrations as the source Worker config.

• Updated dependencies [75d8cb0, 75d8cb0, 75d8cb0, 75d8cb0, 75d8cb0, f10d4ad, 75d8cb0, 75d8cb0, 75d8cb0, 75d8cb0, d292046, 75d8cb0, 75d8cb0, 75d8cb0, 75d8cb0, 75d8cb0, 75d8cb0, e0cc2cb, 75d8cb0, 75d8cb0, 75d8cb0]:

  • wrangler@​4.106.0
  • miniflare@​4.20260630.0

v1.42.3

Compare Source

Patch Changes

• Updated dependencies [5f40dd5, 34e0cef, 3b743c1, daa5389, 8a5cf8c]:
  • wrangler@​4.105.0
  • miniflare@​4.20260625.0

v1.42.2

Compare Source

Patch Changes

• #​14358 4ef872f Thanks @​gabivlj! - Fix container egress interception on arm64 Docker runtimes

  Both wrangler dev and the Cloudflare Vite plugin no longer force the proxy-everything sidecar image to pull as linux/amd64, allowing Docker to select the native image from the multi-platform manifest. Set MINIFLARE_CONTAINER_EGRESS_IMAGE_PLATFORM to force a specific platform when needed.

• Updated dependencies [a085dec, 9a0de8f, fab565f, 3f02864, 4ef872f, 2a02858, e312dec]:

  • miniflare@​4.20260623.0
  • wrangler@​4.104.0

v1.42.1

Compare Source

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]:

  • wrangler@​4.103.0
  • miniflare@​4.20260617.1

v1.42.0

Compare Source

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]:

  • miniflare@​4.20260617.0
  • wrangler@​4.102.0

v1.41.0

Compare Source

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

• Updated dependencies [0e055d3, 27db82c, 2a6a26b, 9a424ed, ecfdd5a, 604be26, 1fb7ba5, 208b3bb, 41f391f, 32f9307, 8b2ce41, 3578919, ee82c76, 41f391f, 21dbc12, 7e63948, 035917f]:
  • miniflare@​4.20260616.0
  • wrangler@​4.101.0

v1.40.2

Compare Source

Patch Changes

• #​14184 e305126 Thanks @​penalosa! - Drop the --config flag from the experimental internal cf-vite delegate binary.

  The wrangler config file is now discovered by cloudflare() itself rather than being passed through, keeping cf-vite's flag surface (--mode, --port, --host, --local) in sync with the sibling cf-wrangler delegate. cf-vite is an internal integration point spawned by Cloudflare tooling and is not intended to be run directly by users.

• Updated dependencies [98c9afe, e305126, f3990b2, 4597f08, 25722ac, 41f75c0, 10b5538, 818c105, 2ae6099, 2047a32, 2047a32, e8561c2]:

  • wrangler@​4.100.0
  • miniflare@​4.20260611.0

v1.40.1

Compare Source

Patch Changes

• Updated dependencies [23aecac, b932e47, d076bcc, 24497d0, 4bb572f, 165adb2, 776098c, 0706fbf, 7993711, 48c4ff0, 8cf8c61, 8923f97, b205fb7, a61ac29]:
  • wrangler@​4.99.0
  • miniflare@​4.20260609.0

v1.40.0

Compare Source

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

• Updated dependencies [c6c61b5, c6c61b5, a3eea27, 7a6b1a4, 7539a9b, 1fdd8de, 3b8b80a, 0bb2d55, 8400fb9, b502d54, 7949f81, d462013, c2280cd, 3b8b80a, ea12b58, acf7817]:
  • wrangler@​4.98.0
  • miniflare@​4.20260603.0

v1.39.2

Compare Source

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]:

  • wrangler@​4.97.0
  • miniflare@​4.20260601.0

v1.39.1

Compare Source

Patch Changes

• #​14087 e3c862a Thanks @​edmundhung! - Filter compatibility date fallback warning when no update is available

  The compatibility date warning from workerd (e.g., "The latest compatibility date supported by the installed Cloudflare Workers Runtime is...") is now only shown when a newer version of @cloudflare/vite-plugin is available. This matches the behavior in Wrangler and reduces noise when the user is already on the latest version.

  The update-check logic has been extracted to @cloudflare/workers-utils so it can be shared across packages.

• #​14080 ec70cf1 Thanks @​edmundhung! - Fix Tunnel closed being logged when no tunnel was opened

  Previously, the Vite plugin printed Tunnel closed during cleanup even when tunnel startup had never begun. This message is now only shown after tunnel startup begins, including when the tunnel is still starting or has already expired.

• Updated dependencies [e3c862a, cbb39bd, cbb39bd, 408432a, 1103c07, 7bb5c7a, 5b5cbd3, e3c862a, e3c862a, 97d7d81, c647ccc, e3c862a, e3c862a, e3c862a, e3c862a, e3c862a, b64b7e4, e3c862a, e3c862a, e4c8fd9, 2dffeeb, e3c862a, e3c862a, 4c0da7b, 972d13d, 13cbadb, 59e43e4]:

  • miniflare@​4.20260529.0
  • wrangler@​4.96.0

v1.39.0

Compare Source

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

• Updated dependencies [ca5b604, c1fd2fd, 49c1a59, fee1ce4, b3962ff, d042705, 420e457, 8b1467e]:
  • wrangler@​4.95.0
  • miniflare@​4.20260526.0

v1.38.0

Compare Source

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

• Updated dependencies [52e9082, 0733688, fc1f7b9, 30657e1, 8c569c6, f598eac, 3a1fbed]:
  • wrangler@​4.94.0
  • miniflare@​4.20260521.0

v1.37.3

Compare Source

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]:

  • miniflare@​4.20260520.0
  • wrangler@​4.93.1

v1.37.2

Compare Source

Patch Changes

• #​13098 67a881a Thanks @​raashish1601! - fix: route WebSocket upgrade requests directly to the user worker in dev mode

• Updated dependencies [aac7ca0, b25dc0d, ae047ee, a4f22bc, f78d435, aac7ca0, c5c9e20, ebf4b24, b27eb18, [895baf5](https://redirect.git

✂ Note

PR body was truncated to here.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.