wrangler loginallows you to authenticate Wrangler to use your Cloudflare user credentials without hunting down an API token in the Cloudflare dashboard. It's straightforward! Just run
wrangler login, enter your credentials, and you're off to the races.
wrangler devas an authenticated user, your requests will now run on the same servers that Cloudflare Workers run on in production. This means that what you see is what you get.
wrangler devshould behave exactly like production, though we still recommend deploying to a staging website before going to production in order to ensure your changes are safe. This change means you get access to things like
request.cf, the Cache API, and any Cloudflare settings you've applied in the dashboard while developing your Workers.
When an HTTP response status code is between 300 and 399, the server lets the client know that the data they're looking for isn't here anymore, and the client should issue another separate request to the endpoint denoted in the
Locationheader of the response. Before, if you were developing with
example.com, and your Worker issued a redirect from
https://example.com/newurl, that's what would be in the
Locationheader. This meant that whatever client you were using would then issue their second request to the public Internet rather than the
wrangler devserver running on your local machine. With this release, the
Locationheader would now be rewritten to
http://127.0.0.1:8787/newurl, preventing your client from redirecting you away from the Worker you're trying to develop.
All commands that read from a configuration file can now use a different configuration file path if the
--configflag is specified. The commands affected are:
wrangler devnow takes two additional configuration flags:
--local-protocol. Both of these take a value of either
--upstream-protocoldetermines what protocol the request going to your preview worker is (previously this was only controlled with the
--hostflag) - this flag defaults to
--local-protocoldetermines what protocol
wrangler devlistens for and defaults to
httpsis chosen, a self-signed certificate will be auto-generated for the dev server.
Any flag taken by
--host) can now be configured in the
[dev]section of your
wrangler.toml. This allows different developers on the same project to share and persist settings for their local development environment.
preview_idis needed, the error message directs the user to add it to their
Before, if you passed an environment to a
wrangler routecommand, it wouldn't work properly due to some mishandling of the arguments in the way we used our command line argument parser. This is now fixed and
wrangler routecommands work as expected.
wrangler preview, the browser is now opened as a child process. This fixes an issue on Linux where Wrangler would start the browser and then hang waiting for the browser to exit before it begins watching for changes.