ReleaseCloudflare (Workers AI)Cloudflare (Workers AI)published Jun 19, 2026seen 6d

cloudflare/workers-sdk wrangler@4.103.0

cloudflare/workers-sdk

Open original ↗

Captured source

source ↗
published Jun 19, 2026seen 6dcaptured 6dhttp 200method plain

wrangler@4.103.0

Repository: cloudflare/workers-sdk

Tag: wrangler@4.103.0

Published: 2026-06-19T13:30:38Z

Prerelease: no

Release notes:

Minor Changes

The unstable_getWorkerNameFromProject export has been removed from the wrangler package. This function is now available as getWorkerNameFromProject (without the unstable_ prefix) from @cloudflare/workers-utils. If you were importing this function from wrangler, update your import to use @cloudflare/workers-utils instead.

The experimental autoconfig exports (experimental_getDetailsForAutoConfig, experimental_runAutoConfig, experimental_AutoConfigFramework) have been removed. This logic has been moved to the @cloudflare/autoconfig package (without the experimental_ prefixes since the package itself is pre-v1).

Patch Changes

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.

When a worker logs many errors in quick succession, the stderr chunks received by wrangler dev can be truncated mid-stack-frame, leaving a call site with an invalid column number. The source map library throws in that case, which was crashing the wrangler process entirely. The error is now caught and the original (un-source-mapped) text is returned instead.

  • #14118 `b38823f` Thanks @aicayzer! - Fix Uint8Array step outputs in local Workflows being persisted with the full backing ArrayBuffer

A Uint8Array returned from a Workflows step under wrangler dev was serialised together with its full underlying ArrayBuffer, causing a raw SQLITE_TOOBIG error at view sizes well below the documented 1MiB step-output limit. For example, a 200KB view sliced from an 800KB buffer (a common pattern from crypto.getRandomValues or arr.slice(...) on a larger pool) would fail. The view's bytes are now copied to a tight buffer before persistence, bringing local behaviour in line with production. Fixes #14101.

  • Updated dependencies [`b38823f`]:
  • miniflare@4.20260617.1

Notability

notability 3.0/10

Routine wrangler CLI release, no AI impact.