Minor Changes
-
#4499
cf9c029b
Thanks @penalosa! - feat: Support runtime-agnostic polyfillsPreviously, 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
intoesbuild
's bundle settings as a predefined constant, which means thatesbuild
can tree-shake away imports ofnode:*
APIs that are guaranteed not to be hit at runtime, supressing the warning entirely. -
#4926
a14bd1d9
Thanks @dario-piotrowicz! - feature: add acf
field to thegetBindingsProxy
resultAdd a new
cf
field to thegetBindingsProxy
result that people can use to mock the production
cf
(IncomingRequestCfProperties
) object.Example:
const { cf } = await getBindingsProxy(); console.log(`country = ${cf.country}; colo = ${cf.colo}`);
Patch Changes
-
#4931
321c7ed7
Thanks @dario-piotrowicz! - fix: make the entrypoint optional for thetypes
commandCurrently running
wrangler types
against awrangler.toml
file without a defined entrypoint (main
value)
causes the command to error with the following message:✘ [ERROR] Missing entry-point: The entry-point should be specified via the command line (e.g. `wrangler types path/to/script`) or the `main` config field.
However developers could want to generate types without the entrypoint being defined (for example when using
getBindingsProxy
), so these changes
make the entrypoint optional for thetypes
command, assuming modules syntax if none is specified. -
#4867
d637bd59
Thanks @RamIdeas! - fix: inflight requests to UserWorker which failed across reloads are now retriedPreviously, when running
wrangler dev
, requests inflight during a UserWorker reload (due to config or source file changes) would fail.Now, if those inflight requests are GET or HEAD requests, they will be reproxied against the new UserWorker. This adds to the guarantee that requests made during local development reach the latest worker.
-
#4928
4a735c46
Thanks @sdnts! - fix: Update API calls for Sippy's endpoints -
#4938
75bd08ae
Thanks @rozenmd! - fix: print wrangler banner at the start of every d1 commandThis PR adds a wrangler banner to the start of every D1 command (except when invoked in JSON-mode)
For example:
⛅️ wrangler 3.27.0 ------------------- ...
-
#4953
d96bc7dd
Thanks @mrbbot! - fix: allowport
option to be specified withunstable_dev()
Previously, specifying a non-zero
port
when usingunstable_dev()
would try to start two servers on thatport
. This change ensures we only start the user-facing server on the specifiedport
, allowunstable_dev()
to startup correctly.