Bump wrangler from 3.27.0 to 3.28.1

[dependabot]

Bumps wrangler from 3.27.0 to 3.28.1.

Release notes

Sourced from wrangler's releases.

[email protected]

Patch Changes

• #4962 d6585178 Thanks @​mrbbot! - fix: ensure wrangler dev can reload without crashing when importing node:* modules

  The previous Wrangler release introduced a regression that caused reloads to fail when importing node:* modules. This change fixes that, and ensures these modules can always be resolved.

• #4951 ffafe8ad Thanks @​nora-soderlund! - fix: D1 batch splitting to handle CASE as compound statement starts

[email protected]

Minor Changes

• #4499 cf9c029b Thanks @​penalosa! - feat: Support runtime-agnostic polyfills

  Previously, Wrangler treated any imports of node:* modules as build-time errors (unless one of the two Node.js compatibility modes was enabled). This is sometimes overly aggressive, since those imports are often not hit at runtime (for instance, it was impossible to write a library that worked across Node.JS and Workers, using Node packages only when running in Node). Here's an example of a function that would cause Wrangler to fail to build:

  export function randomBytes(length: number) {
  	if (navigator.userAgent !== "Cloudflare-Workers") {
  		return new Uint8Array(require("node:crypto").randomBytes(length));
  	} else {
  		return crypto.getRandomValues(new Uint8Array(length));
  	}
  }

  This function should work in both Workers and Node, since it gates Node-specific functionality behind a user agent check, and falls back to the built-in Workers crypto API. Instead, Wrangler detected the node:crypto import and failed with the following error:

  ✘ [ERROR] Could not resolve "node:crypto"
  src/randomBytes.ts:5:36:
    5 │ ... return new Uint8Array(require('node:crypto').randomBytes(length));
      ╵                                   ~~~~~~~~~~~~~
  
  The package "node:crypto" wasn't found on the file system but is built into node.
  Add "node_compat = true" to your wrangler.toml file to enable Node.js compatibility.
  

  This change turns that Wrangler build failure into a warning, which users can choose to ignore if they know the import of node:* APIs is safe (because it will never trigger at runtime, for instance):

  ▲ [WARNING] The package "node:crypto" wasn't found on the file system but is built into node.
  Your Worker may throw errors at runtime unless you enable the "nodejs_compat"
  compatibility flag. Refer to
  https://developers.cloudflare.com/workers/runtime-apis/nodejs/ for more details.
  Imported from:
  
  src/randomBytes.ts
  

However, in a lot of cases, it's possible to know at build time whether the import is safe. This change also injects navigator.userAgent into esbuild's bundle settings as a predefined constant, which means that esbuild can tree-shake away imports of node:* APIs that are guaranteed not to be hit at runtime, supressing the warning entirely.

... (truncated)

Changelog

Sourced from wrangler's changelog.

3.28.1

Patch Changes

• #4962 d6585178 Thanks @​mrbbot! - fix: ensure wrangler dev can reload without crashing when importing node:* modules

  The previous Wrangler release introduced a regression that caused reloads to fail when importing node:* modules. This change fixes that, and ensures these modules can always be resolved.

• #4951 ffafe8ad Thanks @​nora-soderlund! - fix: D1 batch splitting to handle CASE as compound statement starts

3.28.0

Minor Changes

• #4499 cf9c029b Thanks @​penalosa! - feat: Support runtime-agnostic polyfills

  Previously, Wrangler treated any imports of node:* modules as build-time errors (unless one of the two Node.js compatibility modes was enabled). This is sometimes overly aggressive, since those imports are often not hit at runtime (for instance, it was impossible to write a library that worked across Node.JS and Workers, using Node packages only when running in Node). Here's an example of a function that would cause Wrangler to fail to build:

  export function randomBytes(length: number) {
  	if (navigator.userAgent !== "Cloudflare-Workers") {
  		return new Uint8Array(require("node:crypto").randomBytes(length));
  	} else {
  		return crypto.getRandomValues(new Uint8Array(length));
  	}
  }

  This function should work in both Workers and Node, since it gates Node-specific functionality behind a user agent check, and falls back to the built-in Workers crypto API. Instead, Wrangler detected the node:crypto import and failed with the following error:

  ✘ [ERROR] Could not resolve "node:crypto"
  src/randomBytes.ts:5:36:
    5 │ ... return new Uint8Array(require('node:crypto').randomBytes(length));
      ╵                                   ~~~~~~~~~~~~~
  
  The package "node:crypto" wasn't found on the file system but is built into node.
  Add "node_compat = true" to your wrangler.toml file to enable Node.js compatibility.
  

  This change turns that Wrangler build failure into a warning, which users can choose to ignore if they know the import of node:* APIs is safe (because it will never trigger at runtime, for instance):

  ▲ [WARNING] The package "node:crypto" wasn't found on the file system but is built into node.
  Your Worker may throw errors at runtime unless you enable the "nodejs_compat"
  compatibility flag. Refer to
  https://developers.cloudflare.com/workers/runtime-apis/nodejs/ for more details.
  Imported from:
  

... (truncated)

Commits

• 96c8cfb Version Packages (#4961)
• d658517 fix: ensure worker reloads when importing node:* modules (#4962)
• ffafe8a [D1] fix batch splitting to handle CASE as compound statement starts (#4951)
• a71afaf Version Packages (#4934)
• d637bd5 Extend error handling of proxy request errors in ProxyWorker (#4867)
• d96bc7d fix: allow port option to be specified with unstable_dev() (#4953)
• 4a735c4 improve(r2): Update Sippy endpoint request payloads to match new schema (#4928)
• cf9c029 Improve DX with node:* modules (#4499)
• a14bd1d add a cf field to the getBindingsProxy result (#4926)
• 321c7ed fix: make the entrypoint optional for the types command (#4931)
• 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 merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)