This repository has been archived by the owner on Aug 3, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What's changed?
Release Candidate 1 adds
wrangler login
, a new way to easily authenticate wrangler using your Cloudflare username and password. Just typewrangler login
, follow the login process, and you'll be authenticated. Release Candidate 1 also adds extra features towrangler dev
. You can now change the protocol of the local serverwrangler 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:Finally the arguments for
wrangler dev
can now be set in yourwrangler.toml
under the[dev]
section. All arguments other than host are valid.Installation
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 fromwrangler dev
and your production worker.Behavior Changes
wrangler dev
will now treat the worker you're developing like it would when you runwrangler publish
. This means you will need to specifyworkers_dev
orzone_id
androute
in your project's configuration file before usingwrangler dev
.routes
specified in your configuration file. Lets say that in production you have a worker running onexample.com/*
and you want to start development of a new worker with a routeexample.com/test
. In this scenario, when you runwrangler dev
, and thencurl 127.0.0.1:8787
you will get a response from the worker currently running in production at the routeexample.com/*
. If you want to test your preview worker, you will need tocurl 127.0.0.1:8787/test
. In this scenario, the request host in the Workers runtime would be https://example.comevent.request.cf
(no longerundefined
)--host
flag is now only used when you are not an authenticated Cloudflare userFeedback
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 withwrangler dev
to match what you see in production. If you'd like to provide feedback onwrangler dev
, you can comment on this issue or file a new one! Just make sure to prefix your issue title with[dev]
.