cloudflare/workers-sdk wrangler@2.0.6

on GitHub

Patch Changes

• #1018 cd2c42f Thanks @threepointone! - fix: strip leading */*. from routes when deducing a host for dev

  When given routes, we use the host name from the route to deduce a zone id to pass along with the host to set with dev session. Route patterns can include leading */*., which we don't account for when deducing said zone id, resulting in subtle errors for the session. This fix strips those leading characters as appropriate.

  Fixes #1002

• #1044 7a191a2 Thanks @JacobMGEvans! - fix: trim trailing whitespace from the secrets before uploading

  resolves #993

• #1052 233eef2 Thanks @petebacondarwin! - fix: display the correct help information when a subcommand is invalid

Previously, when an invalid subcommand was used, such as wrangler r2 foo,
the help that was displayed showed the top-level commands prefixed by the command in used.
E.g.

wrangler r2 init [name]       📥 Create a wrangler.toml configuration file
wrangler r2 dev [script]      👂 Start a local server for developing your worker
wrangler r2 publish [script]  🆙 Publish your Worker to Cloudflare.
...

Now the correct command help is displayed:

$ wrangler r2 foo

✘ [ERROR] Unknown argument: foo

wrangler r2

📦 Interact with an R2 store

Commands:
  wrangler r2 bucket  Manage R2 buckets

Flags:
  -c, --config   Path to .toml configuration file  [string]
  -h, --help     Show help  [boolean]
  -v, --version  Show version number  [boolean]

Fixes #871

• #906 3279f10 Thanks @threepointone! - feat: implement support for service bindings

This adds experimental support for service bindings, aka worker-to-worker bindings. It's lets you "call" a worker from another worker, without incurring any network cost, and (ideally) with much less latency. To use it, define a [services] field in wrangler.toml, which is a map of bindings to worker names (and environment). Let's say you already have a worker named "my-worker" deployed. In another worker's configuration, you can create a service binding to it like so:

[[services]]
binding = "MYWORKER"
service = "my-worker"
environment = "production" # optional, defaults to the worker's `default_environment` for now

And in your worker, you can call it like so:

export default {
  fetch(req, env, ctx) {
    return env.MYWORKER.fetch(new Request("http://domain/some-path"));
  }
};

Fixes #1026

• #1045 8eeef9a Thanks @jrf0110! - fix: Incorrect extension extraction from file paths.

  Our extension extraction logic was taking into account folder names, which can include periods. The logic would incorrectly identify a file path of .well-known/foo as having the extension of well-known/foo when in reality it should be an empty string.

• #1039 95852c3 Thanks @threepointone! - fix: don't fetch migrations when in --dry-run mode

  Fixes #1038

• #1033 ffce3e3 Thanks @petebacondarwin! - fix: wrangler init should not crash if Git is not available on Windows

  We check for the presence of Git by trying to run git --version.
  On non-Windows we get an Error with code set to "ENOENT".
  One Windows we get a different error:

  {
    "shortMessage":"Command failed with exit code 1: git --version",
    "command":"git --version",
    "escapedCommand":"git --version",
    "exitCode":1,
    "stdout":"",
    "stderr":"'git' is not recognized as an internal or external command,\r\noperable program or batch file.",
    "failed":true,
    "timedOut":false,
    "isCanceled":false,
    "killed":false
  }
  

  Since we don't really care what the error is, now we just assume that Git
  is not available if an error is thrown.

  Fixes #1022

• #982 6791703 Thanks @matthewdavidrodgers! - feature: add support for publishing to Custom Domains

  With the release of Custom Domains for workers, users can publish directly to a custom domain on a route, rather than creating a dummy DNS record first and manually pointing the worker over - this adds the same support to wrangler.

  Users declare routes as normal, but to indicate that a route should be treated as a custom domain, a user simply uses the object format in the toml file, but with a new key: custom_domain (i.e. routes = [{ pattern = "api.example.com", custom_domain = true }])

  When wrangler sees a route like this, it peels them off from the rest of the routes and publishes them separately, using the /domains api. This api is very defensive, erroring eagerly if there are conflicts in existing Custom Domains or managed DNS records. In the case of conflicts, wrangler prompts for confirmation, and then retries with parameters to indicate overriding is allowed.

• #1019 5816eba Thanks @threepointone! - feat: bind a durable object by environment

  For durable objects, instead of just { name, class_name, script_name}, this lets you bind by environment as well, like so { name, class_name, script_name, environment }.

  Fixes #996

• #1057 608dcd9 Thanks @petebacondarwin! - fix: pages "command" can consist of multiple words

  On Windows, the following command wrangler pages dev -- foo bar would error
  saying that bar was not a known argument. This is because foo and bar are
  passed to Yargs as separate arguments.

  A workaround is to put the command in quotes: wrangler pages dev -- "foo bar".
  But this fix makes the command argument variadic, which also solves the problem.

  Fixes #965

• #1027 3545e41 Thanks @rozenmd! - feat: trying to use node builtins should recommend you enable node_compat in wrangler.toml

• #1024 110f340 Thanks @threepointone! - polish: validate payload for kv:bulk put on client side

  This adds client side validation for the paylod for kv:bulk put, importantly ensuring we're uploading only string key/value pairs (as well as validation for the other fields).

  Fixes #571

• #1037 963e9e0 Thanks @rozenmd! - fix: don't attempt to login during a --dryRun