github cloudflare/workers-sdk wrangler@0.0.24

latest releases: create-cloudflare@2.32.1, wrangler@3.86.1, @cloudflare/vitest-pool-workers@0.5.27...
2 years ago

Patch Changes

  • #719 6503ace Thanks @petebacondarwin! - fix: ensure the correct worker name is published in legacy environments

    When a developer uses --env to specify an environment name, the Worker name should
    be computed from the top-level Worker name and the environment name.

    When the given environment name does not match those in the wrangler.toml, we error.
    But if no environments have been specified in the wrangler.toml, at all, then we only
    log a warning and continue.

    In this second case, we were reusing the top-level environment, which did not have the
    correct legacy environment fields set, such as the name. Now we ensure that such an
    environment is created as needed.

    See #680 (comment)

  • #708 763dcb6 Thanks @threepointone! - fix: unexpected commands and arguments should throw

    This enables strict mode in our command line parser (yargs), so that unexpected commands and options uniformly throw errors.

    Fixes #706

  • #713 18d09c7 Thanks @threepointone! - fix: don't fetch zone id for wrangler dev --local

    We shouldn't try to resolve a domain/route to a zone id when starting in local mode (since there may not even be network).

  • #692 52ea60f Thanks @threepointone! - fix: do not deploy to workers.dev when routes are defined in an environment

    When workers_dev is not configured, we had a bug where it would default to true inside an environment even when there were routes defined, thus publishing both to a workers.dev subdomain as well as the defined routes. The fix is to default workers_dev to undefined, and check when publishing whether or not to publish to workers.dev/defined routes.

    Fixes #690

  • #687 8f7ac7b Thanks @petebacondarwin! - fix: add warning about wrangler dev with remote Durable Objects

    Durable Objects that are being bound by script_name will not be isolated from the
    live data during development with wrangler dev.
    This change simply warns the developer about this, so that they can back out before
    accidentally changing live data.

    Fixes #319

  • #661 6967086 Thanks @JacobMGEvans! - polish: add "Beta" messaging around the CLI command for Pages. Explicitly specifying the command is Beta, not to be confused with Pages itself which is production ready.

  • #709 7e8ec9a Thanks @threepointone! - fix: trigger login flow if refreshtoken isn't valid

    If the auth refresh token isn't valid, then we should trigger the login flow. Reported in #316

  • #702 241000f Thanks @threepointone! - fix: setup jsx loaders when guessing worker format

    • We consider jsx to be regular js, and have setup our esbuild process to process js/mjs/cjs files as jsx.
    • We use a separate esbuild run on an entry point file when trying to guess the worker format, but hadn't setup the loaders there.
    • So if just the entrypoint file has any jsx in it, then we error because it can't parse the code.

    The fix is to add the same loaders to the esbuild run that guesses the worker format.

    Reported in #701

  • #711 3dac1da Thanks @threepointone! - fix: default wrangler tail to pretty print

    Fixes #707

  • #712 fb53fda Thanks @threepointone! - feat: Non-interactive mode

    Continuing the work from #325, this detects when wrangler is running inside an environment where "raw" mode is not available on stdin, and disables the features for hot keys and the shortcut bar. This also adds stubs for testing local mode functionality in local-mode-tests, and deletes the previous hacky dev2.test.tsx.

    Fixes #322

  • #716 6987cf3 Thanks @threepointone! - feat: path to a custom tsconfig

    This adds a config field and a command line arg tsconfig for passing a path to a custom typescript configuration file. We don't do any typechecking, but we do pass it along to our build process so things like compilerOptions.paths get resolved correctly.

  • #665 62a89c6 Thanks @caass! - fix: validate that bindings have unique names

    We don't want to have, for example, a KV namespace named "DATA"
    and a Durable Object also named "DATA". Then it would be ambiguous
    what exactly would live at env.DATA (or in the case of service workers,
    the DATA global) which could lead to unexpected behavior -- and errors.

    Similarly, we don't want to have multiple resources of the same type
    bound to the same name. If you've been working with some KV namespace
    called "DATA", and you add a second namespace but don't change the binding
    to something else (maybe you're copying-and-pasting and just changed out the id),
    you could be reading entirely the wrong stuff out of your KV store.

    So now we check for those sorts of situations and throw an error if
    we find that we've encountered one.

  • #698 e3e3243 Thanks @threepointone! - feat: inject process.env.NODE_ENV into scripts

    An extremely common pattern in the js ecosystem is to add additional behaviour gated by the value of process.env.NODE_ENV. For example, React leverages it heavily to add dev-time checks and warnings/errors, and to load dev/production versions of code. By doing this substitution ourselves, we can get a significant runtime boost in libraries/code that leverage this.

    This does NOT tackle the additional features of either minification, or proper node compatibility, or injecting wrangler's own environment name, which we will tackle in future PRs.

  • #680 8e2cbaf Thanks @JacobMGEvans! - refactor: support backwards compatibility with environment names and related CLI flags

    1. When in Legacy environment mode we should not compute name field if specified in an environment.
    2. Throw an Error when --env and --name are used together in Legacy Environment, except for Secrets & Tail which are using a special case getLegacyScriptName for parity with Wrangler1
    3. Started the refactor for args being utilized at the Config level, currently checking for Legacy Environment only.

    Fixes #672

  • #684 82ec7c2 Thanks @GregBrimble! - fix: Fix --binding option for wrangler pages dev.

    We'd broken this with #581. This reverts that PR, and fixes it slightly differently. Also added an integration test to ensure we don't regress in the future.

  • #678 82e4143 Thanks @threepointone! - fix: cleanup after pages dev tests

    We weren't killing the process started by wrangler whenever its parent was killed. This fix is to listen on SIGINT/SIGTERM and kill that process. I also did some minor configuration cleanups.

    Fixes #397
    Fixes #618

Don't miss a new workers-sdk release

NewReleases is sending notifications on new releases.