cloudflare/workers-sdk wrangler@2.0.24 on GitHub

Patch Changes

#1577 359d0ba3 Thanks @threepointone! - chore: update esbuild to 0.14.51
#1558 b43a7f98 Thanks @rozenmd! - chore: extract devProps parsing into own function
#1438 0a9fe918 Thanks @caass! - Initial implementation of wrangler generate
- wrangler generate and wrangler generate <name> delegate to wrangler init.
- wrangler generate <name> <template> delegates to create-cloudflare
Naming behavior is replicated from wrangler 1, and will auto-increment the
worker name based on pre-existing directories.
#1534 d3ae16cf Thanks @cameron-robey! - feat: publish full url on wrangler publish for workers.dev workers
When the url is printed out on wrangler publish, the full url is printed out so that it can be accessed from the terminal easily by doing cmd+click. Implemented only for workers.dev workers.
Resolves #1530
#1552 e9307365 Thanks @Skye-31! - fix: invalid regular expression error (pages)
#1576 f696ebb5 Thanks @petebacondarwin! - feat: add platform/os to usage metrics events
#1576 f696ebb5 Thanks @petebacondarwin! - fix: rename pages metrics events to align better with the dashboard
#1550 aca9c3e7 Thanks @cameron-robey! - feat: describe current permissions in wrangler whoami
Often users experience issues due to tokens not having the correct permissions associated with them (often due to new scopes being created for new products). With this, we print out a list of permissions associated with OAuth tokens with the wrangler whoami command to help them debug for OAuth tokens. We cannot access the permissions on an API key, so we direct the user to the location in the dashboard to achieve this.
We also cache the scopes of OAuth tokens alongside the access and refresh tokens in the .wrangler/config file to achieve this.
Currently unable to implement #1371 - instead directs the user to the dashboard.
Resolves #1540
#1575 5b1f68ee Thanks @JacobMGEvans! - feat: legacy "kv-namespace" not supported
In previous Wrangler 1, there was a legacy configuration that was considered a "bug" and removed.
Before it was removed, tutorials, templates, blogs, etc... had utlized that configuration property
to handle this in Wrangler 2 we will throw a blocking error that tell the user to utilize "kv_namespaces"
resolves #1421
#1404 17f5b576 Thanks @threepointone! - feat: add cache control options to config.assets
This adds cache control options to config.assets. This is already supported by the backing library (@cloudflare/kv-asset-handler) so we simply pass on the options at its callsite.
Additionally, this adds a configuration field to serve an app in "single page app" mode, where a root index.html is served for all html/404 requests (also powered by the same library).
#1578 cf552192 Thanks @cameron-robey! - feat: source-map function names
Following on from #1535, using new functionality from esbuild v0.14.50 of generation of names field in generated sourcemaps, we output the original function name in the stack trace.
#1503 ebc1aa57 Thanks @threepointone! - feat: zero config multiworker development (local mode)
Preamble: Typically, a Worker has been the unit of a javascript project on our platform. Any logic that you need, you fit into one worker, ~ 1MB of javascript and bindings. If you wanted to deploy a larger application, you could define different workers on different routes. This is fine for microservice style architectures, but not all projects can be cleaved along the route boundaries; you lose out on sharing code and resources, and can still cross the size limit with heavy dependencies.
Service bindings provide a novel mechanism for composing multiple workers into a unified architecture. You could deploy shared code into a worker, and make requests to it from another worker. This lets you architect your code along functional boundaries, while also providing some relief to the 1MB size limit.
I propose a model for developing multiple bound workers in a single project.
Consider Worker A, at workers/a.js, with a wrangler.toml like so:
```
name = 'A'

[[services]]
binding = 'Bee'
service = 'B'
```
and content like so:
```
export default {
	fetch(req, env) {
		return env.Bee.fetch(req);
	}
};
```
Consider Worker B, at workers/b.js, with a wrangler.toml like so:
```
name = 'B'
```
and content like so:
```
export default {
	fetch(req, env) {
		return new Response("Hello World");
	}
};
```
So, a worker A, bound to B, that simply passes on the request to B.
Local mode:

Currently, when I run wrangler dev --local on A (or switch from remote to local mode during a dev session), and make requests to A, they'll fail because the bindings don't exist in local mode.
What I'd like, is to be able to run wrangler dev --local on B as well, and have my dev instance of A make requests to the dev instance of B. When I'm happy with my changes, I'd simply deploy both workers (again, ideally as a batched publish).
Proposal: A local dev registry for workers.
- Running wrangler dev on a machine should start up a local service registry (if there isn't one loaded already) as a server on a well known port.
- Further, it should then "register" itself with the registry with metadata about itself; whether it's running in remote/local mode, the port and ip its dev server is listening on, and any additional configuration (eg: in remote mode, a couple of extra headers have to be added to every request made to the dev session, so we'd add that data into the registry as well.)
- Every worker that has service bindings configured, should intercept requests to said binding, and instead make a request to the locally running instance of the service. It could rewrite these requests as it pleases.
(In future PRs, we'll introduce a system for doing the same with remote mode dev, as well as mixed mode. )
Related to #1182
Fixes #1040
#1551 1b54b54f Thanks @threepointone! - internal: middleware for modifying worker behaviour
This adds an internal mechanism for applying multiple "middleware"/facades on to workers. This lets us add functionality during dev and/or publish, where we can modify requests or env, or other ideas. (See #1466 for actual usecases)
As part of this, I implemented a simple facade that formats errors in dev. To enable it you need to set an environment variable FORMAT_WRANGLER_ERRORS=true. This isn't a new feature we're shipping with wrangler, it's simply to demonstrate how to write middleware. We'll probably remove it in the future.
#1486 c4e6f156 Thanks @JacobMGEvans! - feat: commands added for uploading and downloading objects from r2.
#1539 95d0f863 Thanks @threepointone! - fix: export durable objects correctly when using --assets
The facade for static assets doesn't export any exports from the entry point, meaning Durable Objects will fail. This fix adds all exports to the facade's exports.
#1564 69713c5c Thanks @JacobMGEvans! - chore: updated wrangler readme providing additional context on configuration, deep link to init and fixing old link to beta docs.
#1581 3da184f1 Thanks @threepointone! - fix: apply multiworker dev facade only when required
This fix makes sure the multiworker dev facade is applied to the input worker only where there are other wrangler dev instances running that are bound to the input worker. We also make sure we don't apply it when we already have a binding (like in remote mode).
#1476 cf9f932a Thanks @alankemp! - Add logfwdr binding
#1576 f696ebb5 Thanks @petebacondarwin! - feat: add metricsEnabled header to CF API calls when developing or deploying a worker
This allows us to estimate from API requests what proportion of Wrangler
instances have enabled usage tracking, without breaking the agreement not
to send data for those who have not opted in.
#1525 a692ace3 Thanks @threepointone! - feat: config.first_party_worker + dev facade
This introduces configuration for marking a worker as a "first party" worker, to be used inside cloudflare to develop workers. It also adds a facade that's applied for first party workers in dev.
#1545 b3424e43 Thanks @Martin-Eriksson! - fix: Throw error if both directory and command is specified for pages dev
The previous behavior was to silently ignore the command argument.
#1574 c61006ca Thanks @jahands! - fix: Retry check-missing call to make wrangler pages publish more reliable
Before uploading files in wrangler pages publish, we make a network call to check what files need to be uploaded. This call could sometimes fail, causing the publish to fail. This change will retry that network call.
#1565 2b5a2e9a Thanks @threepointone! - fix: export durable object bindings when using service bindings in dev
A similar fix to #1539, this exports correctly when using service bindings in dev.
#1510 4dadc414 Thanks @matthewdavidrodgers! - refactor: touch up publishing to custom domains
Couple things cleaned up here:
Originally the usage of the /domains api (for publishing to custom domains) was a bit clumsy: we would attempt to optimistically publish, but the api would eagerly fail with specific error codes on why it occurred. This made for some weird control flow for retries with override flags, as well as fragile extraction of error messages.
Now we use the new /domains/changeset api to generate a changeset of actions required to get to a new state of custom domains, which informs us up front of which domains would need to be updated and overridden, and we can pass flags as needed. I do make an extra hop back to the api to lookup what the custom domains requiring updates are already attached to, but given how helpful I imagine that to be, I'm for it.
I also updated the api used for publishing the domains, from /domains to /domains/records. The latter was added to allow us to add flexibility for things like the /domains/changeset resource, and thus the former is being deprecated
#1576 f696ebb5 Thanks @petebacondarwin! - feat: send whether a Worker is using TypeScript or not in usage events
#1535 eee7333b Thanks @cameron-robey! - feat: source maps support in wrangler dev remote mode
Previously stack traces from runtime errors in wrangler dev remote mode, would give unhelpful stack traces from the bundled build that was sent to the server. Here, we use source maps generated as part of bundling to provide better stack traces for errors, referencing the unbundled files.
Resolves #1509

cloudflare/workers-sdk wrangler@2.0.24 on GitHub

Patch Changes

Local mode:

Proposal: A local dev registry for workers.

cloudflare/workers-sdk wrangler@2.0.24
on GitHub