Deprecations
This document describes the difference between Wrangler 1 and 2, specifically deprecations and breaking changes.
Wrangler 2 introduces some new fields for configuration, while also deprecating some redundant fields.
Common deprecations
Here are common fields that are no longer required.
typeis no longer required. Wrangler will infer the correct project type automatically.zone_idis no longer required. It can be deduced from the routes directly.build.upload.formatis no longer used. The format is now inferred automatically from the code.build.upload.mainandbuild.upload.dirare no longer required. Use the top levelmainfield, which now serves as the entry-point for the Worker.site.entry-pointis no longer required. The entry point should be specified through themainfield.webpack_configandwebpackproperties are no longer supported. Refer to Ejecting Webpack. Here are the Wrangler 1 commands that are no longer supported:wrangler preview- Use thewrangler devcommand, for running your worker in your local environment.wrangler generate- If you want to use a starter template, clone its GitHub repository and manually initialize it.wrangler route- Routes are defined in thewrangler.tomlconfiguration file.wrangler report- If you find a bug please report it at Wrangler issues.wrangler build- If you wish to access the output from bundling your Worker usewrangler publish --outdir=path/to/output.
New fields
These are new fields that can be added to your wrangler.toml.
main:string, optionalThe
mainfield is used to specify an entry point to the Worker. It may be in the established service worker format, or the newer, preferred modules format. An entry point is now explicitly required, and can be configured either via themainfield, or passed directly as a command line, for example,wrangler dev index.js. This field replaces the legacybuild.upload.mainfield (which only applied to modules format Workers).rules:array, optionalThe
rulesfield is an array of mappings between module types and file patterns. It instructs Wrangler to interpret specific files differently than JavaScript. For example, this is useful for reading text-like content as text files, or compiled WASM as ready to instantiate and execute. These rules can apply to Workers of both the established service worker format, and the newer modules format. This field replaces the legacybuild.upload.rulesfield (which only applied to modules format Workers).
Non-mandatory fields
A few configuration fields which were previously required, are now optional in particular situations. They can either be inferred, or added as an optimization. No fields are required anymore when starting with Wrangler 2, and you can gradually add configuration as the need arises.
name:stringThe
nameconfiguration field is now not required forwrangler dev, or any of thewrangler kv:*commands. Further, it can also be passed as a command line argument as--name <name>. It is still required forwrangler publish.account_id:stringThe
account_idfield is not required for any of the commands. Any relevant commands will check if you are logged in, and if not, will prompt you to log in. Once logged in, it will use your account ID and will not prompt you again until your login session expires. If you have multiple account IDs, you will be presented with a list of accounts to choose from.You can still configure
account_idin yourwrangler.tomlfile, or as an environment variableCLOUDFLARE_ACCOUNT_ID; this will make startup faster, and bypass the list of choices if you have multiple IDs. TheCLOUDFLARE_API_TOKENenvironment variable is also useful for situations where it is not possible to login interactively - refer to Running in CI/CD.workers_devboolean, default:truewhen no routes are presentThe
workers_devfield is used to indicate that the Worker should be published to a*.workers.devsubdomain. For example, for a Worker namedmy-workerand a previously configured*.workers.devsubdomainusername, the Worker will get published tomy-worker.username.workers.dev.com. This field is not mandatory, and defaults totruewhenrouteorroutesare not configured. When routes are present, it defaults tofalse. If you want to neither publish it to a*.workers.devsubdomain nor any routes, setworkers_devtofalse. This useful when you are publishing a Worker as a standalone service that can only be accessed from another Worker with (services).
Deprecated fields (non-breaking)
A few configuration fields are deprecated, but their presence is not a breaking change yet. It is recommended to read the warning messages and follow the instructions to migrate to the new configuration. They will be removed and stop working in a future version.
zone_id:string, deprecatedThe
zone_idfield is deprecated and will be removed in a future release. It is now inferred fromroute/routes, and optionally fromdev.hostwhen usingwrangler dev. This also makes it simpler to deploy a single Worker to multiple domains.build.upload:object, deprecatedThe
build.uploadfield is deprecated and will be removed in a future release. Its usage results in a warning with suggestions on rewriting the configuration file to remove the warnings.build.upload.main/build.upload.dirare replaced by themainfields and are applicable to both service worker format and modules format Workers.build.upload.rulesis replaced by therulesfield and is applicable to both service worker format and modules format Workers.build.upload.formatis no longer specified and is automatically inferred bywrangler.
Deprecated fields (breaking)
A few configuration fields are deprecated and will not work as expected anymore. It is recommended to read the error messages and follow the instructions to migrate to the new configuration.
site.entry-point:string, deprecatedThe
site.entry-pointconfiguration was used to specify an entry point for Workers with a[site]configuration. This has been replaced by the top-levelmainfield.type:rust|javascript|webpack, deprecatedThe
typeconfiguration was used to specify the type of Worker. It has since been made redundant and is now inferred from usage. If you were usingtype = "webpack"(and the optionalwebpack_configfield), you should read the webpack migration guide to modify your project and use a custom build instead.
Deprecated commands
The following commands are deprecated in Wrangler as of Wrangler 2.
build
The wrangler build command is no longer available for building the Worker.
The equivalent functionality can be achieved by wrangler publish --dry-run --outdir=path/to/build.
config
The wrangler config command is no longer available for authenticating via an API token.
Use wrangler login / wrangler logout to manage OAuth authentication, or provide an API token via the CLOUDFLARE_API_TOKEN environment variable.
preview
The wrangler preview command is no longer available for creating a temporary preview instance of the Worker.
Try using wrangler dev to try out a worker during development.
subdomain
The wrangler subdomain command is no longer available for creating a workers.dev subdomain.
Create the workers.dev subdomain on your Workers dashboard.
generate
The wrangler generate command is no longer available to initialize a Worker from a template repository.
Initialize a basic Worker project via wrangler init, which provides a good starting point for most projects.
Alternatively, try cloning the template repository and initializing it manually.
route
The wrangler route command is no longer available to configure a route for a Worker.
Routes are specified in the wrangler.toml configuration file.
Other deprecated behaviour
Wrangler will no longer use
index.jsin the directory wherewrangler devis called as the entry point to a Worker. Use themainconfiguration field, or explicitly pass it as a command line argument, for example:wrangler dev index.js.Wrangler will no longer assume that bare specifiers are file names if they are not represented as a path. For example, in a folder like so:
project ├── index.js └── some-dependency.jswhere the content of
index.jsis:import SomeDependency from "some-dependency.js";addEventListener("fetch", (event) => {// ...});Wrangler 1 would resolve
import SomeDependency from "some-dependency.js";to the filesome-dependency.js. This will also work in Wrangler 2, but will also log a deprecation warning. In the future, this will break with an error. Instead, you should rewrite the import to specifiy that it is a relative path, like so:- import SomeDependency from "some-dependency.js";+ import SomeDependency from "./some-dependency.js";