Update dependency @cloudflare/vitest-pool-workers to ^0.18.0#39
Merged
Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
25c3731 to
7bd4c82
Compare
1cb542c to
f23a6b5
Compare
9d61de0 to
a198a82
Compare
a198a82 to
6ecbd57
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^0.16.20→^0.18.0Release Notes
cloudflare/workers-sdk (@cloudflare/vitest-pool-workers)
v0.18.0Compare Source
Minor Changes
#14382
fd92d56Thanks @petebacondarwin! - Add support for declarative Durable Object exportswrangler deploynow accepts anexportsmap inwrangler.jsonas a declarative alternative to the legacymigrationsarray.Each entry in
exportsis keyed by Durable Object class name.typecarries the export kind (currently always"durable-object"); thestatefield 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
migrationsarray nor anexportsmap), wrangler warns and now suggests a declarativeexportsentry for each class (previously it suggested a legacymigrationsblock).The deployment response now surfaces the server's reconciliation result — created namespaces, applied tombstones, structured per-scenario info entries, and a
removable_entrieshint 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 uploadalso forwardsexports. Declarativeexportslifecycle changes are reconciled when the version is deployed (wrangler versions deployorwrangler deploy), so aversions uploadpayload can declare new classes inexportswithout immediately provisioning them. An actor binding (durable_objects.bindings) to a class declared only inexportson the sameversions uploadis rejected with a clear error (code 100406) — the binding cannot be resolved until the namespace is provisioned. Either stage the new class viactx.exports.X(no binding required) onversions uploadand add the binding at deploy time, or usewrangler deployto provision and bind in one step (the same constraint applies to themigrationsflow).Multi-version deploys (
wrangler versions deploy A@50% B@50%) where the selected versions disagree on declarativeexportsare rejected server-side with a clear message: deploy the version that changesexportsat 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 devandunstable_startWorker) reads Durable Object SQLite storage settings from the newexportsfield, so applications using the declarative flow get correct local-dev storage without needing to also declare amigrationsblock.@cloudflare/vitest-pool-workersalso picks up Durable Object configuration fromexports, so tests against anexports-only Worker run with the correct local SQLite storage and can reach unbound Durable Object classes viactx.exports.X.wrangler typesis also aware ofexports. Live entries (includingexpecting-transfer, the receiving side of a two-phase transfer) are added toCloudflare.GlobalProps.durableNamespaces, which typesctx.exports.Xfor unbound Durable Objects declared only viaexports.Patch Changes
aa5d580,6b0ce98,fd92d56,bfe48db,be3f792,0277bfa,98793d8,e1532eb]:v0.17.0Compare Source
Minor Changes
#14490
75d8cb0Thanks @petebacondarwin! - Make Workflow introspectorget()asyncThe
introspectWorkflow(...).get()method now returns a promise, so callers must await it:This aligns Workflow introspection with the shared implementation used by
createTestHarness().Patch Changes
#14490
75d8cb0Thanks @petebacondarwin! - Supportrequire("./x.wasm?module")in CommonJS dependenciesPreviously, only literal
await import("./x.wasm?module")specifiers were rewritten through the static analysis path added in #11094. CommonJS dependencies that userequire("./x.wasm?module")reach the module-fallback service at runtime, where the?modulesuffix went unhandled. The fallback either failed withNo such module "<abs>/x.wasm?module"or, when aCompiledWasmrule was configured, attempted to evaluate the WebAssembly bytes as JavaScript.However, these
require()s work in deployed workers because esbuild's bundler statically rewrites theserequire()calls into ES dynamic imports. vitest-pool-workers' Vite-based pipeline doesn't do that rewrite and instead defers to the module-fallback at runtime.The module-fallback now strips
?modulefrom the resolved target and synthesizes a CommonJS wrapper that re-requires the underlying.wasmby absolute path, exposing it ondefaultto match what workerd produces forCompiledWasmmodules.Updated dependencies [
75d8cb0,75d8cb0,75d8cb0,75d8cb0,75d8cb0,f10d4ad,75d8cb0,75d8cb0,75d8cb0,75d8cb0,d292046,75d8cb0,75d8cb0,75d8cb0,75d8cb0,75d8cb0,75d8cb0,e0cc2cb,75d8cb0,75d8cb0,75d8cb0]:Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.