Bump the packages group across 1 directory with 6 updates

[dependabot]

Bumps the packages group with 4 updates in the / directory: prettier, typescript-eslint, @types/chrome and @cloudflare/vitest-pool-workers.

Updates prettier from 3.9.3 to 3.9.4

Release notes

Sourced from prettier's releases.

3.9.4

• Angular: Format @content(name) -> @content (name) to align with other block syntax (#19499 by @​fisker)

🔗 Changelog

Changelog

Sourced from prettier's changelog.

3.9.4

diff

Angular: Format @content(name) -> @content (name) to align with other block syntax (#19499 by @​fisker)

<!-- Input -->
<FancyButton [label]="title">
  @content (icon) {
    <span>Icon!</span>
  }
  @content (description) {
    <span>Description text</span>
  }
  <span>Other children</span>
</FancyButton>
<!-- Prettier 3.9.3 -->
<FancyButton [label]="title">
@​content(icon) {
<span>Icon!</span>
}
@​content(description) {
<span>Description text</span>
}
<span>Other children</span>
</FancyButton>
<!-- Prettier 3.9.4 -->
<FancyButton [label]="title">
@​content (icon) {
<span>Icon!</span>
}
@​content (description) {
<span>Description text</span>
}
<span>Other children</span>
</FancyButton>

Commits

• b693cb2 Release 3.9.4
• 2e92ac0 Angular: Format @content(name) -> @content (name) to align with other blo...
• abed2c2 Bump Prettier dependency to 3.9.3
• 6cfbc00 Clean changelog_unreleased
• See full diff in compare view

Updates typescript-eslint from 8.62.0 to 8.62.1

Release notes

Sourced from typescript-eslint's releases.

v8.62.1

8.62.1 (2026-06-29)

🩹 Fixes

• eslint-plugin: [prefer-optional-chain] use suggestion instead of autofix for trailing binary operator (#12328)
• eslint-plugin: [no-unnecessary-boolean-literal-compare] preserve boolean result in fixer for nullable true comparisons (#12365)
• eslint-plugin: [no-unnecessary-type-assertion] parenthesize object literal at left edge of expression statement (#12443, #12418)

❤️ Thank You

• Kirk Waiblinger @​kirkwaiblinger
• mdm317
• Patrick Aleite
• 송재욱

See GitHub Releases for more information.

You can read about our versioning strategy and releases on our website.

Changelog

Sourced from typescript-eslint's changelog.

8.62.1 (2026-06-29)

This was a version bump only for typescript-eslint to align it with other projects, there were no code changes.

See GitHub Releases for more information.

You can read about our versioning strategy and releases on our website.

Commits

• 3ea32f4 chore(release): publish 8.62.1
• See full diff in compare view

Updates @types/chrome from 0.2.0 to 0.2.2

Commits

• See full diff in compare view

Updates @cloudflare/vitest-pool-workers from 0.16.20 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...
• See full diff in compare view

Updates @cloudflare/workers-types from 4.20260629.1 to 4.20260702.1

Commits

• See full diff in compare view

Updates wrangler from 4.105.0 to 4.107.0

Release notes

Sourced from wrangler's releases.

wrangler@4.107.0

Minor Changes

• #14474 aa5d580 Thanks @​WillTaylorDev! - Add cache options for WorkerEntrypoint exports

  You can now set cache options on WorkerEntrypoint exports and configure cross-version cache behavior globally:

  // wrangler.json
  {
    "cache": { "enabled": true, "cross_version_cache": true },
    "exports": {
      "default": {
        "type": "worker",
        "cache": { "enabled": false }
      },
      "Admin": {
        "type": "worker",
        "cache": { "enabled": true }
      }
    }
  }

  Wrangler sends the exports config to the deploy and version upload APIs alongside the global cache.enabled and cache.cross_version_cache settings. The platform resolves those global settings plus cache overrides on exports and validates which entrypoint names are cacheable.

• #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",

... (truncated)

Commits

• 473e61f Version Packages (#14503)
• c8dbcf5 [wrangler] Remove experimental gate for declarative Durable Object exports (#...
• 98793d8 [wrangler] Improve asset upload performance with single-file uploads (#14305)
• be3f792 [wrangler] Add wrangler flagship commands (#14423)
• e1532eb [wrangler] Add opt-in OS keychain storage for OAuth credentials (#14156)
• aa5d580 WC-5321 Add cache options for WorkerEntrypoint exports (#14474)
• fd92d56 [wrangler] Add experimental support for declarative Durable Object exports (#...
• 0277bfa Improve error message when deploying to a non-existent Pages project in non-i...
• bfe48db [wrangler] fix: remove stale --experimental-vm-modules flag and prevent silen...
• 6b0ce98 Bump the workerd-and-workers-types group with 2 updates (#14502)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions