Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

[email protected]

Patch Changes

• #675 e88a54e Thanks @threepointone! - fix: resolve non-js modules correctly in local mode

  In Custom Miniflare CLI #633, we missed passing a cwd to the process that runs the miniflare cli. This broke how miniflare resolves modules, and led back to the dreaded "path should be a path.relative()d string" error. The fix is to simply pass the cwd to the spawn call.

  Test plan:

  cd packages/wrangler
  npm run build
  cd ../workers-chat-demo
  npx wrangler dev --local
  

• #668 3dcdb0d Thanks @petebacondarwin! - fix: tighten up the named environment configuration

  Now, when we normalize and validate the raw config, we pass in the currently
  active environment name, and the config that is returned contains all the
  environment fields correctly normalized (including inheritance) at the top
  level of the config object. This avoids other commands from having to check
  both the current named environment and the top-level config for such fields.

  Also, now, handle the case where the active environment name passed in via the
  --env command line argument does not match any of the named environments
  in the configuration:

  • This is an error if there are named environments configured;
  • or only a warning if there are no named environments configured.

• #633 003f3c4 Thanks @JacobMGEvans! - refactor: create a custom CLI wrapper around Miniflare API

  This allows us to tightly control the options that are passed to Miniflare.
  The current CLI is setup to be more compatible with how Wrangler 1 works, which is not optimal for Wrangler 2.

• #633 84c857e Thanks @JacobMGEvans! - fix: ensure asset keys are relative to the project root

  Previously, asset file paths were computed relative to the current working
  directory, even if we had used -c to run Wrangler on a project in a different
  directory to the current one.

  Now, assets file paths are computed relative to the "project root", which is
  either the directory containing the wrangler.toml or the current working directory
  if there is no config specified.

• #673 456e1da Thanks @petebacondarwin! - fix: allow the build field to be inherited/overridden in a named environment"

  Now the build field can be specified within a named environment, overriding whatever
  may appear at the top level.

  Resolves config.build should be inheritable  #588

• #650 d3d1ff8 Thanks @petebacondarwin! - feat: make main an inheritable environment field

  See #588

• #650 f0eed7f Thanks @petebacondarwin! - fix: make validation error messages more consistent

• #662 612952b Thanks @JacobMGEvans! - bugfix: use alias -e for --env to prevent scripts using Wrangler 1 from breaking when switching to Wrangler 2.

• #671 ef0aaad Thanks @GregBrimble! - fix: don't exit on initial Pages Functions compilation failure

  Previously, we'd exit the wrangler pages dev process if we couldn't immediately compile a Worker from the functions directory. We now log the error, but don't exit the process. This means that proxy processes can be cleaned up cleanly on SIGINT and SIGTERM, and it matches the behavior of if a compilation error is introduced once already running (we don't exit then either).

• #667 e29a241 Thanks @threepointone! - fix: delete unused [site] assets

  We discovered critical issues with the way we expire unused assets with [site] (see 🐛 BUG: bulk put: could not base64 decode value for key #666, Expiration changes hanging deploys wrangler-legacy#2224), that we're going back to the legacy manner of handling unused assets, i.e- deleting unused assets.

  Fixes 🐛 BUG: bulk put: could not base64 decode value for key #666

• #640 2a2d50c Thanks @caass! - Error if the user is trying to implement DO's in a service worker

  Durable Objects can only be implemented in Module Workers, so we should throw if we detect that
  the user is trying to implement a Durable Object but their worker is in Service Worker format.

[threepointone]

so changesets is using an older version of prettier, which removes the parentheses, which then fails our check (changesets/changesets#616). I think a fix for us is to simply not run prettier --check on this one file, or we'll keep failing releases.

[threepointone]

so changesets is using an older version of prettier, which removes the parentheses, which then fails our check (changesets/changesets#616). I think a fix for us is to simply not run prettier --check on this one file, or we'll keep failing releases.

[threepointone]

#664