chore: bump the cloudflare group across 1 directory with 2 updates

[dependabot]

Bumps the cloudflare group with 2 updates in the / directory: @cloudflare/vitest-pool-workers and @cloudflare/workers-types.

Updates @cloudflare/vitest-pool-workers from 0.7.8 to 0.18.0

Release notes

Sourced from @​cloudflare/vitest-pool-workers's releases.

@​cloudflare/vitest-pool-workers@​0.18.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.

... (truncated)

Changelog

Sourced from @​cloudflare/vitest-pool-workers's changelog.

0.18.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.

... (truncated)

Commits

• 473e61f Version Packages (#14503)
• c8dbcf5 [wrangler] Remove experimental gate for declarative Durable Object exports (#...
• fd92d56 [wrangler] Add experimental support for declarative Durable Object exports (#...
• 13c69dd Version Packages (#14487)
• 75d8cb0 Revert "Version Packages" (#14490)
• 5e6950b Version Packages (#14433)
• 6b14c5b feat(wrangler): introspect workflow with test harness (#14438)
• f7ce796 [vitest-pool-workers] Support require("./x.wasm?module") in CommonJS deps (#1...
• 8eacfd1 Replace all the occurrences of the deprecated toThrowError API with the app...
• 70d97d9 Version Packages (#14401)
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for @​cloudflare/vitest-pool-workers since your current version.

Updates @cloudflare/workers-types from 4.20260702.1 to 5.20260703.1

Commits

• See full diff in compare view

[dependabot]

Labels

The following labels could not be found: dependencies. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.