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

Releases: cloudflare/wrangler-legacy

🐈 1.8.2

12 Mar 19:20
Compare
Choose a tag to compare
  • 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.

😈 1.8.1

03 Mar 23:24
0f5289e
Compare
Choose a tag to compare
  • 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.

πŸ™Š 1.8.0

26 Feb 03:53
Compare
Choose a tag to compare
  • 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!

      Preview

    • 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:

      Github Actions - Test Status

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

Read more

πŸ₯¨ 1.8.0-rc.2

20 Feb 22:22
Compare
Choose a tag to compare
πŸ₯¨ 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...

Read more

🌈 1.8.0-rc.1

18 Feb 17:15
Compare
Choose a tag to compare
🌈 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.

🀠1.8.0-rc.0

12 Feb 23:38
Compare
Choose a tag to compare
🀠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.

πŸ’¬ 1.7.0

05 Feb 21:15
Compare
Choose a tag to compare
  • 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.

🎰 1.6.0

20 Nov 17:41
Compare
Choose a tag to compare
  • 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

  • Documentation

Read more

v1.6.0-rc.0

11 Nov 20:26
Compare
Choose a tag to compare

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

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/[email protected] -g

Install the Wrangler release candidate:

Run this command in your terminal:

npm i @cloudflare/[email protected] -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...
Read more

πŸ‘» 1.5.0

26 Oct 16:27
Compare
Choose a tag to compare
  • 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...

Read more