🔐 v1.11.0-rc.1

What's changed?

Release Candidate 1 adds wrangler login, a new way to easily authenticate wrangler using your Cloudflare username and password. Just type wrangler login, follow the login process, and you'll be authenticated. Release Candidate 1 also adds extra features to wrangler dev. You can now change the protocol of the local server wrangler dev creates and how those requests are forwarded with the --local-protocol and --upstream-protocol arguments. For example, this is what it would look like if you wanted the local server to use https:

$ wrangler dev --local-protocol=https
💁  JavaScript project found. Skipping unnecessary build!
💁  watching "./"
👂  Listening on https://127.0.0.1:8787
💁  Generated certificate is not verified, browsers will give a warning and curl will require `--insecure`
[2020-08-13 12:03:39] GET worker.ftc.workers.dev/ HTTP/1.1 200 OK

Finally the arguments for wrangler dev can now be set in your wrangler.toml under the [dev] section. All arguments other than host are valid.

name = "worker"
type = "javascript"
account_id = "acountidslkfdjskldfjslkdjfls"
workers_dev = true
route = ""
zone_id = "zoneidjalsdkfjlskd324svadvdf"

[dev]
ip="127.0.0.1"
port=8787
local_protocol="http"
upstream_protocol="https"

Installation

npm i @cloudflare/wrangler@beta -g

Creating a project

The documentation below assumes you have some familiarity with Wrangler and are already developing Workers. If this is not the case that is OK, come back after you've read through our Quickstart and have gotten up and running with Wrangler.

Testing the new wrangler dev

If you're already familiar with wrangler dev, you'll know that it spins up a development server that you can use to test the functionality of your Worker. With this release, wrangler dev will now connect directly to an instance of the Cloudflare Workers runtime running on the same servers that your code runs on in production. This will enable you to use the Cache API and should eliminate any inconsistency between responses from wrangler dev and your production worker.

Behavior Changes

• wrangler dev will now treat the worker you're developing like it would when you run wrangler publish. This means you will need to specify workers_dev or zone_id and route in your project's configuration file before using wrangler dev.
• For workers running on your own domain, your development worker will only run on the routes specified in your configuration file. Lets say that in production you have a worker running on example.com/* and you want to start development of a new worker with a route example.com/test. In this scenario, when you run wrangler dev, and then curl 127.0.0.1:8787 you will get a response from the worker currently running in production at the route example.com/*. If you want to test your preview worker, you will need to curl 127.0.0.1:8787/test. In this scenario, the request host in the Workers runtime would be https://example.com
• For workers running on workers.dev, the request host will be https://projectname.yoursubdomain.workers.dev
• You can now test your Worker's caching behavior with the Cache API
• You can now test your Worker with event.request.cf (no longer undefined)
• The --host flag is now only used when you are not an authenticated Cloudflare user

Feedback

We'd like to know if you notice any different behavior between requests made to a wrangler dev instance, and requests made after you publish your Worker. We want your experience with wrangler dev to match what you see in production. If you'd like to provide feedback on wrangler dev, you can comment on this issue or file a new one! Just make sure to prefix your issue title with [dev].