This repository has been archived by the owner on Aug 3, 2023. It is now read-only.

12 Mar 19:20

github-actions

v1.8.2

1275091

🐈 1.8.2

Features
- Configurable binary host URL - noherczeg, pull/1018
  
  Previously, binaries installed by Wrangler were all assumed to come from npm. If you work in a controlled environment and can only install binaries from a specific endpoint (instead of npm), you can now specify that endpoint using the WRANGLER_BINARY_HOST environment variable.
Fixes
- Eliminate downtime when redeploying Workers Sites - ashleymichal, issue/783, pull/1115
  
  When Workers Sites were first introduced, redeploying a site could lead to a few seconds of downtime if the Worker upload fails. Specifically, if a new Workers Sites upload failed, it was possible that the old, now-unused files in Workers KV would be deleted anyways, meaning that the preexisting Workers Site would suddenly have missing resources. This fix waits to delete now-unused files until after a new Workers Sites script is published.
Maintenance
- Add npm badge to README - tomByrer, pull/1121
  
  Add badge to README that points to npm page for Wrangler.
- Unify attention-grabbing messages - EverlastingBugstopper, pull/1128
  
  Use more actionable, easy-to-read information printouts throughout Wrangler.

Assets 6

03 Mar 23:24

github-actions

v1.8.1

0f5289e

😈 1.8.1

Features
- Error messaging for internet required to talk to Cloudflare API - EverlastingBugstopper, issue/1093 pull/1114
  
  With the release of wrangler dev in 1.8.0, it was not clear to users that internet is required since the feature communicates with Cloudflare's API. With this error message, users without internet connection are shown actionable next steps - check internet connection and lastly check if Cloudflare's API is down.
Fixes
- Fix live reload for wrangler dev - EverlastingBugstopper, issue/1082 pull/1117
  
  wrangler dev re-builds and re-uploads your script to the Cloudflare API when it detects a file change. The Cloudflare API returns a new token which allows wrangler dev to route subsequent requests to the new script. Previously, wrangler dev would re-build, re-upload, and receive the new token, but it wouldn't use it for a couple of minutes due to some faulty threading logic. (darn mutexes!) After this change, wrangler dev will block incoming requests when it is switching the token, thus fixing the issue.
- Remove unneeded carriage return in wrangler secret put - gabbifish, issue/1109 pull/1112
  
  Previously, interactive input from wrangler secret put added a carriage return to the secret key/value pairs on Windows. This no longer happens and input is parsed properly before uploading.

Assets 6

26 Feb 03:53

github-actions

v1.8.0

fe4cc4b

🙊 1.8.0

Features
- wrangler dev - [EverlastingBugstopper], issue/845 pull/883
  
  wrangler dev is a local proxy server to Cloudflare's preview service, allowing you to automatically re-build and preview your application on localhost. This feature is in alpha and we're looking for feedback and bug reports: check out this issue!
  
  wrangler dev works very similarly to wrangler preview, but instead of opening your browser to preview your Worker, it will start a server on localhost that will execute your Worker on incoming HTTP requests:
```
$ wrangler dev
```
  You should be able to send HTTP requests to localhost:8787, along with any headers or other request data, and your Worker should execute as expected. Additionally, you'll see console.log messages and exceptions appearing in your terminal (!!!).
  
  For more information on wrangler dev's options, such as passing a custom host, ip, or port, run wrangler dev in your terminal for the available flags and options.
- Multi-route support - [ashleymichal], issue/866 pull/916
  
  Wrangler now allows developers to publish their Workers projects to multiple routes on a Cloudflare zone.
  
  To deploy your Workers project to multiple routes, you can migrate from the route key to routes:
```
name = "worker"
type = "javascript"
account_id = "youraccountid"
# change this line
# route = "example.com/foo/*"
# to this line
routes = ["example.com/foo/*", "example.com/bar/*"]
zone_id = "yourzoneid"
```
- wrangler secret commands - [ashleymichal], [bradyjoslin], issue/907 issue/909 issue/912 pull/1045
  
  Wrangler now allows developers to use secrets in their Workers codebase. Secrets are secure values that can be accessed as constants, similar to text variables, inside of your Workers code.
  
  To set a secret, you can use wrangler secret put MY_SECRET_NAME. The interactive prompt will ask for the secret text you'd like to add to your project:
```
$ wrangler secret put MY_SECRET_NAME
Enter the secret text you'd like assigned to the variable MY_SECRET_NAME on the script named my-project
```
  Importantly, secrets are constrained to an environment, and do not carry over between different deployed Workers (e.g. my-worker and my-worker-production). This allows you to use different API keys, URLs, and other common "environment variable"-style values in your different environments. Specifying an environment can be done using the --env (or -e, for short):
```
$ wrangler secret put MY_SECRET_NAME --env production
Enter the secret text you'd like assigned to the variable MY_SECRET_NAME on the script named my-project-production
```
  The wrangler secret subcommand also allows developers to list and delete secrets for your Workers projects:
```
$ wrangler secret delete MY_SECRET_NAME
Are you sure you want to permanently delete the variable MY_SECRET_NAME on the script named my-project [y/n] y
🌀  Deleting the secret MY_SECRET_NAME on script my-project.
✨  You've deleted the secret MY_SECRET_NAME.
$ wrangler secret list
[{"name":"API_KEY","type":"secret_text"},{"name":"MY_OTHER_SECRET","type":"secret_text"}]
```
- Plain text binding support - [EverlastingBugstopper] - issue/993 pull/1014
  In addition to secrets, Wrangler now also supports setting "plain text" bindings – values that will be available as constants in your Workers code, but aren't encrypted. This can be done by passing values in wrangler.toml under the vars key:
```
name = "worker"
type = "javascript"
account_id = "your-account-id"
workers_dev = true
vars = { ENV = "staging" }
[env.prod]
vars = { ENV = "production" }
```
- Return accounts and account IDs when running wrangler whoami - [ashleygwilliams], issue/630 pull/983
  
  We've made big improvements to wrangler whoami, and now return a list of Cloudflare accounts and account IDs for your authenticated user. If you are unauthenticated, or something is wrong with your API key or token, we'll also return an error with this command to help you understand how to fix your authentication issues!
- Configure sourcemap file - [xtuc], issue/681 pull/1063
  
  webpack (by default) emits a sourcemap that maps to a main.js file, which doesn't match the Workers runtime's configured filename, worker.js. This causes exception reporting tools to be unable to process a Workers sourcemap file – we've updated our Webpack config to output the file worker.js and have fixed this issue.
- Upload "draft" worker if secret is created before initial worker script has been uploaded - [gabbifish], issue/913 pull/1087
  
  If your script hasn't yet been deployed to the Workers platform, creating and deleting secrets will also create a "draft" Worker – allowing you to still manage secret bindings before you deploy the first version of your script.
Maintenance
- Correctly tar release binaries - [EverlastingBugstopper], issue/1055 pull/1062
  
  This PR updates the way that release binaries are generated during Wrangler's release workflow.
- Change NPM binary permissions - [xtuc], pull/1058
  
  This PR removes an unnecessary executable permission from npm/binary.js.
- Improvements to GitHub Actions build process - [EverlastingBugstopper], pull/1037
  
  This PR adds a number of improvements to wrangler's GitHub Actions workflows, including caching, release management, and more granular trigger conditions.
- Add GitHub Actions badge to README - [EverlastingBugstopper], pull/1030
  
  This PR adds a GitHub Actions badge to our README, indicating whether the repo's builds are currently passing:
- Test Rust with GitHub Actions - [EverlastingBugstopper], pull/1028
  This PR adds a GitHub Actions workflow for running wrangler's test suite on a number of platforms and Rust versions.
- Add release checklist - [EverlastingBugstopper], pull/1021
  
  This PR adds a release checklist, documenting the steps that we use to release new versions of Wrangler. That checklist includes writing this CHANGELOG - very meta!!!
- Update dependencies - [EverlastingBugstopper], pull/1000
  
  This PR updates some project dependencies as a result of running cargo update.
- Run CI on pull requests, not pushes - [EverlastingBugstopper], pull/1090
  
  This PR changes the GitHub Actions workflow "event trigger" to fire on pull_request, not push. This will allow wrangler's GitHub Actions workflows to run on PRs sent from forks!
- Zip .tar files in CI - [EverlastingBugstopper], pull/1069 pull/1080
  
  These PRs fix some issues in the GitHub Actions release workflow that were causing release artifacts to be incorrectly generated.
- Fixes clippy warnings - [EverlastingBugstopper], pull/1071
  
  This PR fixes some linting issues surfaced by clippy throughout the project.
- Extract upload and deploy to lib modules - [ashleymichal], [pull/1075]
  
  This PR refactors some of the underlying code used inside of wrangler publish, to create two higher-level upload and deploy modules. This work has already been used to support "draft workers" in #1087, and to reduce duplication of code between wrangler preview, `wr...

Assets 6

20 Feb 22:22

github-actions

v1.8.0-rc.2

cd13d32

🥨 1.8.0-rc.2 Pre-release

Pre-release

Getting Started

What's Changed?

Since 1.8.0-rc.1:

Secrets can now be created before publishing a worker for the first time
wrangler secret list no longer returns an error if there are no secrets to list

Since 1.8.0-rc.0:

The text field in wrangler.toml has been renamed to vars
vars in environments no longer inherit from the top level, they must be redefined in each environment
wrangler dev has colorful output for log messages
wrangler whoami lists the account IDs and zone IDs associated with the currently authenticated user

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.

Thanks!

Thanks for trying these features out! We're really excited, there's some really cool stuff in here :)

Features

There are three main features in this release candidate which each have their own individual testing instructions:

Local Development Server (wrangler dev)
Secrets/Per-environment Variables
Multi-route Deploys

Testing `wrangler dev`

DISCLAIMER

This feature is in alpha and almost definitely has bugs.

The way you use wrangler dev in the future may be slightly different than you use it today so please, proceed with caution!

Usage

$ wrangler dev --help
👂  Start a local server for developing your worker

USAGE:
    wrangler dev [OPTIONS]

FLAGS:
        --help    Prints help information

OPTIONS:
    -e, --env <env>      environment to build
    -h, --host <host>    domain to test behind your worker. defaults to example.com
    -i, --ip <ip>        ip to listsen on. defaults to localhost
    -p, --port <port>    port to listen on. defaults to 8787

Workers

wrangler dev works very similarly to wrangler preview except that instead of opening your browser to preview your worker, it will start a server on localhost that will execute your worker on incoming HTTP requests. From there you can use cURL, Postman, your browser, or any other HTTP client to test the behavior of your worker before publishing it.

You should run wrangler dev from your worker directory, and if your worker makes any requests to a backend, you should specify the host with --host example.com.

From here you should be able to send HTTP requests to localhost:8787 along with any headers and paths, and your worker should execute as expected. Additionally, you should see console.log messages and exceptions appearing in your terminal. If either of these things don't happen, or you think the output is incorrect, please file an issue!

You should be able to use cURL, Postman, and any other HTTP client you'd like with this.

Workers Sites

wrangler dev should work with Workers Sites as well! If your site has some sort of configuration for the base url, you'll want to change them to point to localhost:8787 instead of the usual. Then you can just run wrangler dev with the same configuration options outlined above.

Feedback

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].

Advanced

If you'd like for wrangler dev to listen on something other than localhost, you can pass something like --ip 127.0.0.1. This may be useful if you want to test with Docker.

You can also pass --port 8000 if you are already using port 8787 for something else.

Very Advanced

If you would like to try something that hasn't been tested yet, you could try to put a worker in front of something you're running on localhost.

Let's say you have a react app that you're developing locally and it's running on localhost:4000 and you want to also develop a worker at the same time (maybe play around with the new HTMLRewriter API a bit). Unfortunately, you cannot call $ wrangler dev --host localhost:4000 because Cloudflare's preview service needs the back end to be a public URL.

What you can do instead is spin up a TryCloudflare endpoint and pass that url to the --host argument of wrangler dev and then develop them in tandem.

This is a completely unpaved path that has not been tested at all so your mileage may vary. If you get it to work, we'd love to hear about it!

Testing Text / Secret Environment Variable Support

Adding secrets to a new project

To add a secret to your project, from project root run wrangler secret put <SECRET_NAME>, then type in your secret when prompted. You can also run wrangler secret list at any time to see the names of secrets you already have bound to your worker.

Now, modify your script to access the secret and return it in the response:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

/**
 * Respond with secret text
 * @param {Request} request
 */
async function handleRequest(request) {
  return new Response(`this was super secret! ${SECRET_NAME}`, {
    headers: { 'content-type': 'text/plain' },
  })
}

Run wrangler preview and you should see the browser pop up with the Cloudflare Workers preview and your response.

Note: secrets require authentication for use; if you see an error saying that wrangler fell back to unauthenticated preview, try adding your account_id to your wrangler.toml, or re-run wrangler config

Migrating secrets from KV

If you already have a project using KV to store secrets, it's easy to migrate to using secrets.

Let's use an example of a Worker that calls a third party API using an API token. It might look something like this if you are using KV to store the token:

example script:

async function handleRequest(request) {
  // With secrets, we can remove this line...
  let API_TOKEN = await KV_SECRETS.get("API_TOKEN")
  let init = {
    headers: {
      'content-type': 'application/json;charset=UTF-8',
      // ...and use our API_TOKEN variable directly here
      'authorization': `Bearer ${API_TOKEN}`,
    },
  }
  const response = await fetch('https://example.com/api/resource', init)
  const result = await response.json()
  return new Response(result, { headers: { 'content-type': 'application/json;charset=UTF-8' } })
}

addEventListener('fetch', event => {
  return event.respondWith(handleRequest(event.request))
})

example wrangler.toml:

name = "worker"
type = "javascript"
account_id = "youraccountid"
# remove this line
kv-namespaces = [{ id = "kvnamespaceid", binding = "KV_SECRETS" }]

From the command line, run wrangler secret put API_TOKEN. You will be prompted to provide your secret here. You can also pipe a secret to the command in the case of CI:

$ echo "secretapitokenshhdontpeek" | wrangler secret put API_TOKEN

Environments

Secrets are scoped to each script, so if you are developing across multiple environments in Wrangler, you'll want to set secrets individually on each environment. Like other Wrangler commands, secret commands accept an --env flag specifying the named environment in your wrangler.toml.

for example, given this wrangler.toml:

name = "worker"
type = "javascript"
account_id = "youraccountid"

[env.prod]

if you want to make the API_TOKEN secret for your prod env, you would run

$ wrangler secret put API_TOKEN --env prod

Adding plain text variables to your project

In addition to Secrets, you can also add simple text variables to your Worker. These can be handy when you want to use the same script file, but flip behavior based on "environment". Let's try a simple one where we use a global "ENV" to tell our Worker whether it is in "production" or "staging".

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

/**
 * Respond with hello worker text
 * @param {Request} request
 */
async function handleRequest(request) {
  return new Response(`this worker is running in ${ENV}`, {
    headers: { 'content-type': 'text/plain' },
  })
}

In your wrangler.toml, add the following:

name = "worker"
type = "javascript"
account_id = "your-account-id"
workers_dev = true
vars = { ENV = "staging" }
[env.prod]
vars = { ENV = "production" }

Now, if you run wrangler preview, you should get back the response this worker is running in staging. If you then run wrangler preview --env prod, you should get back the response this worker is running in production. ✨

Inheritance and text vars

Inheritance is disabled for text vars beacuse if you want a variable to be set for every environment, it should be defined in your Worker code and not in your wrangler.toml.

name = "worker"
type = "javascript"
account_id = "your-account-id"
workers_dev = true
vars = { ENV = "staging", hostname = "https://worker.example.workers.dev" }

[env.prod]
vars = { ENV = "production", hostname = "https://example.com"  }

Feedback

We love bug reports!!! But we also love any feedback on terminal messaging, including success messages, error messages, etc. Please feel free to file an issue with any feedback or bug reports.

Testing Multi Route Support

Update your `wrangler.toml` to use `routes`

If you are deploying Workers to a zone on Cloudflare (as opposed to deploying to a subdomain on workers.dev), you can now specify multiple routes in your wrangler.toml file! Jus...

Assets 6

18 Feb 17:15

github-actions

v1.8.0-rc.1

cda6985

🌈 1.8.0-rc.1 Pre-release

Pre-release

This beta release is now out of date. If you previously installed this release, you should reinstall with npm i -g @cloudflare/wrangler@beta and see what's changed in the latest release.

Assets 6

12 Feb 23:38

github-actions

v1.8.0-rc.0

0364f3e

🤠1.8.0-rc.0 Pre-release

Pre-release

This beta release is now out of date. If you previously installed this release, you should reinstall with npm i -g @cloudflare/wrangler@beta and see what's changed in the latest release.

Assets 6

05 Feb 21:15

ashleygwilliams

v1.7.0

f8ad9d0

💬 1.7.0

Features
- Do not factor in .gitignore into workers sites upload directory traversal - gabbifish, issue/958 pull/981
  
  This change ensures that the wrangler include/exclude logic for Workers Sites bucket directory traversal does NOT take into account .gitignore, since best practice for static site generators is to put your build directory into your .gitignore.
- Update cloudflare-rs, reqwest, http, uuid - ashleymichal, issue/301 pull/1009
  
  These dependency updates may look like routine maintenance, but this reqwest version actually makes support for corporate proxies possible!
- Add progress bar during Site upload - gabbifish, issue/906 pull/956
  
  Larger static asset uploads in Wrangler now show a progress bar based on the bulk uploads being made.
- Allow custom webpack config for Workers Sites projects - ashleymichal, issue/905 pull/957
  
  Previously we blocked users from declaring webpack_config in their wrangler.toml, as it can be relatively confusing due to the nested nature of the workers-site directory. We removed that block, and added a friendly help message when webpack build fails and the user has a custom webpack_config declared.
- Reformat config api-key output - bradyjoslin, issue/889 pull/910
  
  We care a lot about our error output. Now the output from wrangler config is consistent between calls with and without the --api-key flag.
- Improve error message for wrangler init --site when wrangler.toml already exists - ashleygwilliams, issue/648 pull/931
  
  wrangler init generally expects that you don't already have a wrangler.toml present; however it is common that users want to add static site functionality to their existing wrangler project and will try using wrangler init to do so. Rather than simply complaining that the toml already exists, now we add the workers-site directory to the project, and print out the suggested configuration to add to wrangler.toml. Much nicer!
- Add a helpful error message on authentication error - EverlastingBugstopper, issue/492 pull/932
  
  Previously, when wrangler publish ran into authentication errors, the API result would just print to the screen. Now, it prints a helpful hint to users to re-run wrangler config to fix the error.
- Provide helpful error when user accidentally puts kv-namespace config under [site] - gabbifish, issue/798 pull/937
  
  TOML formatting can be tricky, specifically tables, so it is common for users unfamiliar with the format to accidentally nest attributes inside tables without intending it. In this case, if a user adds a kv-namespaces entry to the bottom of a toml with [site] configuration already declared, it is parsed as a part of the [site] table, rather than as a top-level key. The error output from this is not super helpful, as it just says "unknown field kv-namespaces" which isn't precisely correct.
  
  This PR detects when this error occurs and provides a help suggestion to put kv-namespaces ABOVE the [site] table entry to fix the problem.
Fixes
- Don't install wasm-pack for webpack type projects - EverlastingBugstopper, issue/745 pull/849
  
  You may have noticed that Wrangler installs wasm-pack for your webpack projects, which may seem strange since it's the tool we use to build Rust projects. The reason for this is because you can also build Rust using wasm-pack and webpack in tandem if you use the wasm-pack-plugin. This plugin recently added support for handling the installation of wasm-pack which means Wrangler no longer needs to handle those installs.
Maintenance
- Make Azure use latest rustc - EverlastingBugstopper, issue/887 pull/893
  
  Updates our CI to update the rust toolchain to the latest stable version after installation.
- Fix nightly builds - EverlastingBugstopper, pull/895, pull/898
  
  Now we confirm Wrangler builds against nightly Rust releases!
- Fix compiler warnings on windows - uma0317, issue/800 pull/919
  
  We build Wrangler for Mac OSX, Linux, and Windows, and each of these environments has slightly different needs at compile time. In this case, community contributor uma0317 added configuration that eliminated unused imports for Windows at compile time.
- Remove deprecated kv-namespace config check - ashleymichal, pull/929
  
  Back in 1.1.0, we introduced more robust support for adding KV namespaces to your project. It was a breaking change for users who were still using our first pass at configuration for this in their toml, so we added a friendly error message telling them how to update their wrangler.toml. At this point, all of our users have safely transitioned onto the new syntax, and so we removed the warning; any lingering use of the old syntax will be met with a parse error instead.
- Use binary-install for npm - EverlastingBugstopper, pull/862
  
  This extracts a lot of the logic in Wrangler's installer to an external package, binary-install, which we will also use for installing wasm-pack on webpack project builds. Switching to this package also has the added benefit of cleaning up the downloaded binary on npm uninstall -g @cloudflare/wrangler.

Assets 6

20 Nov 17:41

ashleygwilliams

v1.6.0

96b29fd

🎰 1.6.0

Features
- BREAKING CHANGE: Require the webpack_config field in wrangler.toml to build with a custom configuration - EverlastingBugstopper, issue/296 pull/847
  
  Wrangler will no longer use a webpack.config.js at the root of your project to build your worker. If you would like to continue using a custom build configuration, you will need to specify the webpack_config field in your wrangler.toml like so:
```
name = "my-worker"
workers_dev = true
account_id = "01234567890987654321234567890"
webpack_config = "webpack.config.js"
```
- API Token Support - gabbifish/ashleymichal, issue/354 pull/471/pull/879
  
  Wrangler can now be configured with API Tokens!
  
  Don't worry, current configurations with an email address and a Global API Key will continue to work, but we highly recommend that you switch to API Tokens as they are a much more secure authentication method.
  
  If you want to use API tokens, create an API token from the "Edit Cloudflare Workers" API token template here, and copy/paste it in the wrangler config prompt. Alternatively, you can set the CF_API_TOKEN environment variable.
- Add the ability to preview without opening the browser - EverlastingBugstopper, issue/256 pull/816
  
  wrangler preview can now be called with a --headless flag that will not open the browser.
- Check for valid credentials when running wrangler config - gabbifish, issue/439 pull/842
  
  Before this version of Wrangler, wrangler config would allow any input string to be passed for your user details. Now, Wrangler validates that the credentials will work with Cloudflare's API.
- Add a warning when publishing a Workers Site to a route without a trailing asterisk - EverlastingBugstopper, issue/814 pull/839
  
  When publishing a Workers Site to your own domain, it's important that the Worker code runs on every path on your domain. This isn't particularly clear, so now when attempting to publish a Workers Site to a route without a trailing asterisk, Wrangler will print a warning message.
- Better error message for publishing to a duplicate route - pradovic, issue/519 pull/813
  
  When publishing to a route that is associated with another worker, Wrangler now prints a more actionable error message.
- Better error message when webpack fails - ashleymichal, issue/428 pull/837
  
  Wrangler now recommends running npm install as a possible remedy for failed webpack builds.
Fixes
- Properly handle errors when running Wrangler as a global npm package - jaredmcdonald, issue/848 pull/857
- Clean up temporary build files - EverlastingBugstopper, pull/853
  
  When building a script, Wrangler creates a temporary file. Old versions of Wrangler were quite messy about it, but now it cleans up after itself.
- Fix the help text for wrangler generate - EverlastingBugstopper, pull/830
  
  The default value for a template is now a complete and valid URL instead of a sample project name.
- Remove --version on subcommands - EverlastingBugstopper, issue/791 pull/829
  
  Each subcommand in Wrangler used to take a --version argument which would print the name of the subcommand. For instance, wrangler publish --version would print wrangler-publish. This wasn't super helpful, so we've removed that functionality.
- Fix a broken link in the README - victoriabernard92, pull/838
Maintenance
- Create fixtures programatically - EverlastingBugstopper, pull/854
  
  Wrangler's test suite relied on a large number of fixtures that it read in from the file system. Now, it writes the test fixtures itself and does not rely on reading fixtures from the file system.
- Clean up Workers Sites logic - ashleymichal, issue/622 issue/643 pull/851
- Call cloudflare-rs from https.rs - gabbifish, pull/841
  
  We've refactored some of our API client code in order to make way for some future improvements.
- Audit code comments - EverlastingBugstopper, pull/846
- Update the author of the npm package - EverlastingBugstopper, pull/836
  
  The author of the npm package is now wrangler@cloudflare.com
- Remove unused code warnings when running tests - pradovic, issue/818 pull/832
  
  Due to the way the Rust compiler works, some of our test code appeared to be unused, even though it wasn't really. After making a couple of modules public, there are no more warnings.
- Use the same binding name for Rust and webpack wasm modules - ashleymichal, pull/822
- Move the code for each subcommand to its own directory - EverlastingBugstopper, pull/831
- Refactor upload forms - ashleymichal, pull/826
  
  We've separated some tangled logic regarding the form Wrangler POSTs to the Cloudflare v4 API.
- Pull npm version from package.json - EverlastingBugstopper, issue/812 pull/817
  
  Wrangler's npm installer version now only needs updating in the package.json instead of both the package.json and the source code.
Documentation
- Move Wrangler docs from READMEs to the Cloudflare Workers documentation site - victoriabernard92, pull/823
  
  Wrangler has outgrown the README as primary documentation paradigm, and we've moved its documentation to the Cloudflare Workers documentation site.
- Update the demo gif in the README - EverlastingBugstopper, [issue/843] pull/868
  
  The demo gif at the top of the README now accurately reflects the behavior of the latest Wrangler release.

Assets 6

11 Nov 20:26

ashleygwilliams

v1.6.0-rc.0

4353c81

v1.6.0-rc.0

Testing Guide

Thank you so much for offering to test our upcoming release of Wrangler 1.6.0!

This release includes some fun new features, like

API Token first authentication
deprecation of implicit custom webpack builds

Setup

Prerequisites:

To install Wrangler, you will need to have Node.js installed. To install Node.js, we recommend a Node.js version manager:

OSX/Linux: https://github.com/nvm-sh/nvm#install--update-script

Windows: https://github.com/nullivex/nodist#installation

If you already have Wrangler installed, run:

cargo uninstall wrangler
npm i @cloudflare/wrangler@1.6.0-rc.0 -g

Install the Wrangler release candidate:

Run this command in your terminal:

npm i @cloudflare/wrangler@1.6.0-rc.0 -g

To test that you have installed the right version run:

wrangler --version

You should see this output:

👷 ✨  wrangler 1.6.0-rc.0

Configure Wrangler (using ✨API Tokens!✨)

Even if you previously had Wrangler installed, you should still do this step in order to test our new API tokens feature. API Tokens are more secure than Global API keys and provide more granular control to your account.

Run this in your terminal:

wrangler config

Wrangler will prompt you to enter an API token, which you can create here. Make sure you select the "Edit Cloudflare Workers" token template, otherwise some operations may not work as expected.

Tasks

We'd like you to test scenarios containing a few tasks each. Please try to use the documentation we've provided. If you find the documentation is incomplete or that you need to ask a question, please note that for us! We'd like the documentation to be as self-serve as possible.

1. Register a subdomain/get your subdomain

Run wrangler subdomain and see if you like the new output - try running wrangler subdomain <name> to register a subdomain (even if you already have) and note the output and if it makes sense.

NOTE: If you are creating a subdomain, your API token will need to also have #organization:edit permissions. You can add this permission to the token you generate via the API token UI.

2. Start a Workers Site from scratch

Beginning with nothing, let's build a Workers Site. Some HTML knowledge may be helpful for testers!

Docs: https://developers.cloudflare.com/workers/sites/start-from-scratch/

Tasks:

Preview your site using wrangler preview
Publish your site to workers.dev or to your zone using wrangler publish

3. Deploy a worker with a custom webpack build (optional)

If you're already deploying a worker with a custom webpack build, you will need to update your wrangler.toml to point to your configuration. Wrangler will no longer assume that you want to build your worker when the webpack.config.js at the root of your project.

See bugs?

If you run into bugs or think docs can be improved, please file a ticket at https://github.com/cloudflare/wrangler/issues :) Thank you so much for helping us prep our upcoming Wrangler release!

Changes:

4353c81 1.6.0-rc.0
4a23cab Merge pull request #839 from cloudflare/avery/route-66
a4bcb4d Change failure back to warn
2f14322 Adds error message for site with non-trailing asterisk
d35d6ba Add credential checking logic when auth params are provided in wrangler config (#842)
6a7d66b Remove the fixtures directory (#854)
c3deb57 Merge pull request #857 from jaredmcdonald/master
9906791 Merge branch 'master' into master
cb5d7f3 Merge pull request #851 from cloudflare/alewis/use-entry-point
46d8894 Merge branch 'master' into alewis/use-entry-point

See More

9f61258 Merge branch 'master' into master
b6e6360 Refactor cloudflare-rs cli to be called from http.rs (#841)
553c7dc run-wrangler.js: send error to stderr and exit 1 if child process has an error
f2b7cb9 Merge branch 'master' into alewis/use-entry-point
158c280 Merge pull request #853 from cloudflare/avery/cleanup-wranglerjs
aa7bb4e Merge branch 'master' into avery/cleanup-wranglerjs
ad573cd Merge pull request #847 from cloudflare/avery/require-webpack
8721ba6 DRY up message per Avery's comment
eb94d00 refactor: use PathBuf for bucket
afdd023 Clean up wranglerjs temp file
4c8a1d9 Make preview test pass
6cba9be Fix webpack tests
f70826b 💅: log::info!
7a43fb8 refactor: make scaffold_worker a method on site
83e8f49 Site.entry_point: Option -> Option
0bd86ba Update webpack tests
be310df Require webpack_config to build with custom configuration
7b97084 Merge pull request #846 from cloudflare/avery/fix-comment-formatting
412079e Webpack -> webpack
e6234e6 Update labels in CONTRIBUTING
49dc0fe Replace sven todo with issue link
f5fb490 fix spacing in comment
aa52099 remove the from comment
c217022 FIXME -> TODO
cb23be8 Audit comments
0ccf501 Merge pull request #844 from cloudflare/avery/remove-api-token-msg
cb4b078 Merge branch 'master' into avery/remove-api-token-msg
1ff00b6 Merge pull request #816 from cloudflare/avery/mario-beats-browser
defdb0c Merge branch 'master' into avery/mario-beats-browser
8f5fda2 Add link to API Token creation
0c937ff Merge pull request #838 from cloudflare/victoria/quickfix
ceacb4e Merge branch 'master' into victoria/quickfix
639b7f1 Merge pull request #837 from cloudflare/alewis/warn-node-modules
49a6cdd Add help suggestion on webpack failure
588deb2 Introduce enum for GlobalUser to handle distinct authentication methods (token vs global api key) (#835)
b58fc6f Fix link in readme
15db829 Merge branch 'master' into avery/mario-beats-browser
42acc7a Merge pull request #836 from cloudflare/avery/update-npm-authors
d4d9a07 Update author of npm package to wrangler@
e1e08f6 Add API token support (#471)
c56805e Merge pull request #832 from pradovic/fix/test-code-warnings
3950282 Merge branch 'master' into fix/test-code-warnings
2fde3f0 Merge branch 'master' into avery/mario-beats-browser
9106cf8 Switch from --terminal to --headless
cd58b34 Merge pull request #830 from cloudflare/avery/fix-generate-help
fbdbc7c Merge branch 'master' into avery/mario-beats-browser
2c2c4a8 Merge branch 'master' into avery/fix-generate-help
7e694e8 Merge branch 'master' into fix/test-code-warnings
7a3ae83 Merge pull request #822 from cloudflare/alewis/fix#358
2ba8b93 Merge branch 'master' into fix/test-code-warnings
983fa76 cargo fmt
d16788d pub mod in tests to avoid unused code warnings
86b4783 Merge branch 'master' into alewis/fix#358
932b1e9 Merge branch 'master' into avery/fix-generate-help
e928e22 Merge pull request #831 from cloudflare/avery/to-each-their-own-directory
017781b Merge branch 'master' into avery/to-each-their-own-directory
edc49bc Merge pull request #829 from cloudflare/avery/very-sion
1dbfe5e Merge branch 'master' into avery/very-sion
62c9447 Put each subcommand in its own directory
dc949a4 Fix default value for wrangler generate template
e32448e Remove --version on subcommands
daa873a Merge pull request #823 from cloudflare/victoria/docs-move
9817123 Merge branch 'master' into victoria/docs-move
5669baa Match wasm binding name in webpack to rust default
d9ca44c...

Assets 6

26 Oct 16:27

ashleygwilliams

v1.5.0

9eabc0f

👻 1.5.0

Features
- Deprecate wrangler publish --release - [EverlastingBugstopper], issue/538 pull/751
  
  wrangler publish --release is now simply an alias of wrangler publish. This is related to the introduction of environments made in 1.3.1 and is intended to reduce confusion surrounding deploy targets. Previously, wrangler publish --release would deploy to a route on your own domain, and wrangler publish would deploy to your workers.dev subdomain. This was a confusing API, and we now require individual environments to have either workers_dev = true or both a route and zone_id in each section of wrangler.toml. This makes it very clear where your Workers code is being deployed. If you're not using wrangler publish --release but you added workers_dev = false to the top level of your wrangler.toml because Wrangler warned you to - you can now safely remove it! If you are using wrangler publish --release, know that it is functionally the same as wrangler publish. If you want to deploy to workers.dev and also a route on your own domain, you will need to set up multiple environments.
- Deprecate private field in wrangler.toml - stevenfranks, issue/782 pull/782
  
  In a related note, the private field no longer functions in wrangler.toml. The original intent behind this field was to allow "publishing" without "activating". Unfortunately this led to a lot of undefined behavior if the value was switched from true to false in between a wrangler publish command and a wrangler publish --release command and vice versa. With the removal of wrangler publish --release, we are also removing the private field. If your wrangler.toml files contain a value for private, you can remove it!
- Include/exclude static assets in a Workers Sites project - gabbifish, issue/716 pull/760
  
  Your wrangler.toml has two new optional fields: include and exclude. These fields give you more granular control over what files are uploaded to Workers KV. This behavior mirrors Cargo's include/exclude functionality. Further documentation for this feature is available here.
- A more robust wrangler generate - [EverlastingBugstopper], issue/315 pull/759
  
  wrangler generate is now much smarter about wrangler.toml files. Previously, wrangler generate would simply create the same configuration for every project, and it would ignore any wrangler.toml that was committed to the template. This means much less guesswork when using wrangler generate with existing Workers projects.
- Add the ability to check if you've already registered a workers.dev subdomain - gusvargas, issue/701 pull/747
  
  You can now run wrangler subdomain without any arguments to see if you have registered a workers.dev subdomain.
```
$ wrangler subdomain
💁  foo.workers.dev
```
- Add --verbose flag to wrangler publish and wrangler preview - gabbifish, issue/657 pull/790
  
  You can now run wrangler publish --verbose and wrangler preview --verbose on a Workers Sites project to view all of the files that are being uploaded to Workers KV.
```
$ wrangler publish --verbose
🌀  Using namespace for Workers Site "__example-workers_sites_assets"
💁  Preparing to upload updated files...
🌀  Preparing ./public/favicon.ico
🌀  Preparing ./public/index.html
🌀  Preparing ./public/404.html
🌀  Preparing ./public/img/404-wrangler-ferris.gif
🌀  Preparing ./public/img/200-wrangler-ferris.gif
✨  Success
✨  Built successfully, built project size is 11 KiB.
✨  Successfully published your script to https://test.example.workers.dev
```
- Disallow node_modules as a bucket for Workers Sites - gabbifish, issue/723 pull/792
  
  node_modules is no longer allowed to be a bucket for Workers Sites. It is notoriously very large and if it were specified as a bucket it would probably be a very expensive mistake.
- Allow installs to utilize Wrangler binaries via a caching proxy instead of Github directly - gabbifish, [pull/797]
  
  To avoid dependency on one external service, Github, we enabled a cache proxy (using Workers!) for installations of Wrangler.
- Provide a better error message when using an unverified email address - [ashleygwilliams], issue/320 pull/795
  
  The Cloudflare API refuses to play nice with unverified email addresses (we don't like spam!), and now when this happens, Wrangler gives an actionable error message.
Fixes
- Fix Rust live preview - gabbifish, issue/618 pull/699
  
  If you use Wrangler to develop Rust Workers, you may have noticed that live preview (wrangler preview --watch) was not working with your project. Not to worry though, we cracked down on this bug with an (oxidized) iron fist! Wrangler now has cross-platform support for live previewing Rust Workers.
- Minimize timeout errors for bulk uploads - gabbifish, issue/746 pull/757
  
  Sometimes Wrangler would make API calls to Workers KV that would timeout if there were too many files. We've increased the amount of time Wrangler will wait around for the API operations to complete.
- Print readable error message when external commands fail - [EverlastingBugstopper], pull/799
  
  Wrangler depends on a few external applications, and sometimes the calls to them fail! When this happens, Wrangler would tell you the command it tried to run, but it included a bunch of quotes. This change removes those quotes so the command is easily readable and can be copy/pasted.
- Disallow wrangler generate --site with a template argument - [EverlastingBugstopper], issue/776 pull/789
  
  In Wrangler 1.4.0, we introduced Workers Sites, which included the ability to run wrangler generate --site which would use our site template behind the scenes. Confusingly, you could also pass a template to this command: wrangler generate my-site https://github.com/example/worker-site --site, which would not behave as expected. This specific usage will now correctly output an error.
Maintenance
- Begin refactoring test suite - [ashleymichal], pull/787
  
  We're constantly shipping features in Wrangler, and with more features comes a larger codebase. As a codebase expands, it goes through some growing pains. This release includes some improvements to the internal organization of Wrangler's codebase, and is intended to make our lives and our contributors' lives easier moving forward.
  - Moved all "fixture" helper functions to "utils" module to share between build/preview tests
  - Removed "metadata_wasm.json" from simple_rust fixture
  - Extracted all module declrations in main.rs to lib.rs to allow tests to import with use wrangler::foo
  - Split target/mod.rs into one file per struct
  - Cleaned up KV Namespace mod system
  - Use log::info! instead of info! in main.rs
- Refactor GlobalUser to be passed as a reference consistently - gabbifish, pull/749
- Remove internal link from CONTRIBUTING.md - adaptive, pull/784
- Fix some Clippy warnings - [EverlastingBugstopper], pull/793
- Clean up leftover directories created by tests - [ashleymichal], pull/785
- **Refactor subdomain module - [EverlastingBugstopper], [issue/7...

Assets 6

Releases: cloudflare/wrangler-legacy

🐈 1.8.2

Features

Fixes

Maintenance

😈 1.8.1

Features

Fixes

🙊 1.8.0

Features

Maintenance

🥨 1.8.0-rc.2

Getting Started

What's Changed?

Installation

Creating a project

Thanks!

Features

Testing wrangler dev

DISCLAIMER

Usage

Workers

Workers Sites

Feedback

Advanced

Very Advanced

Testing Text / Secret Environment Variable Support

Adding secrets to a new project

Migrating secrets from KV

Environments

Adding plain text variables to your project

Inheritance and text vars

Feedback

Testing Multi Route Support

Update your wrangler.toml to use routes

🌈 1.8.0-rc.1

🤠1.8.0-rc.0

💬 1.7.0

Features

Fixes

Maintenance

🎰 1.6.0

Features

Fixes

Maintenance

Documentation

v1.6.0-rc.0

Testing Guide

Setup

Prerequisites:

Configure Wrangler (using ✨API Tokens!✨)

Tasks

1. Register a subdomain/get your subdomain

2. Start a Workers Site from scratch

3. Deploy a worker with a custom webpack build (optional)

See bugs?

Changes:

👻 1.5.0

Features

Fixes

Maintenance

Testing `wrangler dev`

Update your `wrangler.toml` to use `routes`