diff --git a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/authentication.mdx b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/authentication.mdx index 631aaf3f5272156..a730f36f7a408da 100644 --- a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/authentication.mdx +++ b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/authentication.mdx @@ -3,6 +3,7 @@ pcx_content_type: how-to title: Authentication sidebar: order: 2 +noindex: true --- import { Render } from "~/components"; diff --git a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands.mdx b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands.mdx index 530803672453dac..96e3dc816385041 100644 --- a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands.mdx +++ b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands.mdx @@ -6,6 +6,7 @@ sidebar: head: - tag: title content: Commands - Wrangler v1 (deprecated) +noindex: true --- import { Render, Type, MetaInfo, WranglerConfig } from "~/components"; @@ -540,8 +541,6 @@ Most `kv` commands require you to specify a namespace. A namespace can be specif Most `kv` subcommands also allow you to specify an environment with the optional `--env` flag. This allows you to publish Workers running the same code but with different namespaces. For example, you could use separate staging and production namespaces for KV data in your Wrangler file: - - ```toml diff --git a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration.mdx b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration.mdx index 3f0110a4d34837f..2e6bc5d12498d3b 100644 --- a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration.mdx +++ b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration.mdx @@ -7,10 +7,10 @@ head: - tag: title content: Configuration - Wrangler v1 (deprecated) description: Learn how to configure your Cloudflare Worker using Wrangler v1. This guide covers top-level and environment-specific settings, key types, and deployment options. - +noindex: true --- -import { Render, WranglerConfig } from "~/components" +import { Render, WranglerConfig } from "~/components"; @@ -18,7 +18,7 @@ import { Render, WranglerConfig } from "~/components" Your project will need some configuration before you can publish your Worker. Configuration is done through changes to keys and values stored in a Wrangler file located in the root of your project directory. You must manually edit this file to edit your keys and values before you can publish. -*** +--- ## Environments @@ -51,18 +51,16 @@ Environment configuration (optional): the configuration values you specify under Environments allow you to deploy the same project to multiple places under multiple names. These environments are utilized with the `--env` or `-e` flag on the [commands](/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands/) that are deploying live Workers: -* `build` -* `dev` -* `preview` -* `publish` -* `secret` +- `build` +- `dev` +- `preview` +- `publish` +- `secret` -Some environment properties can be [*inherited*](#keys) from the top-level configuration, but if new values are configured in an environment, they will always override those at the top level. +Some environment properties can be [_inherited_](#keys) from the top-level configuration, but if new values are configured in an environment, they will always override those at the top level. An example of an `[env.name]` configuration looks like this: - - ```toml @@ -102,89 +100,83 @@ preview_id = "999..." To deploy this example Worker to the `helloworld` environment, you would run `wrangler publish --env helloworld`. -*** +--- ## Keys There are three types of keys in a Wrangler file: -* Top level only keys are required to be configured at the top level of your Wrangler file only; multiple environments on the same project must share this key's value. +- Top level only keys are required to be configured at the top level of your Wrangler file only; multiple environments on the same project must share this key's value. -* Inherited keys can be configured at the top level and/or environment. If the key is defined only at the top level, the environment will use the key's value from the top level. If the key is defined in the environment, the environment value will override the top-level value. +- Inherited keys can be configured at the top level and/or environment. If the key is defined only at the top level, the environment will use the key's value from the top level. If the key is defined in the environment, the environment value will override the top-level value. -* Non-inherited keys must be defined for every environment individually. +- Non-inherited keys must be defined for every environment individually. +- `name` inherited required + - The name of your Worker script. If inherited, your environment name will be appended to the top level. -* `name` inherited required +- `type` top level required - * The name of your Worker script. If inherited, your environment name will be appended to the top level. - -* `type` top level required - - * Specifies how `wrangler build` will build your project. There are three options: `javascript`, `webpack`, and `rust`. `javascript` checks for a build command specified in the `[build]` section, `webpack` builds your project using webpack v4, and `rust` compiles the Rust in your project to WebAssembly. + - Specifies how `wrangler build` will build your project. There are three options: `javascript`, `webpack`, and `rust`. `javascript` checks for a build command specified in the `[build]` section, `webpack` builds your project using webpack v4, and `rust` compiles the Rust in your project to WebAssembly. :::note - Cloudflare will continue to support `rust` and `webpack` project types, but recommends using the `javascript` project type and specifying a custom [`build`](#build) section. - ::: -* `account_id` inherited required - - * This is the ID of the account associated with your zone. You might have more than one account, so make sure to use the ID of the account associated with the `zone_id` you provide, if you provide one. It can also be specified through the `CF_ACCOUNT_ID` environment variable. +- `account_id` inherited required -* `zone_id` inherited optional + - This is the ID of the account associated with your zone. You might have more than one account, so make sure to use the ID of the account associated with the `zone_id` you provide, if you provide one. It can also be specified through the `CF_ACCOUNT_ID` environment variable. - * This is the ID of the zone or domain you want to run your Worker on. It can also be specified through the `CF_ZONE_ID` environment variable. This key is optional if you are using only a `*.workers.dev` subdomain. +- `zone_id` inherited optional -* `workers_dev` inherited optional + - This is the ID of the zone or domain you want to run your Worker on. It can also be specified through the `CF_ZONE_ID` environment variable. This key is optional if you are using only a `*.workers.dev` subdomain. - * This is a boolean flag that specifies if your Worker will be deployed to your [`*.workers.dev`](https://workers.dev) subdomain. If omitted, it defaults to false. +- `workers_dev` inherited optional -* `route` not inherited optional + - This is a boolean flag that specifies if your Worker will be deployed to your [`*.workers.dev`](https://workers.dev) subdomain. If omitted, it defaults to false. - * A route, specified by URL pattern, on your zone that you would like to run your Worker on.
`route = "http://example.com/*"`. A `route` OR `routes` key is only required if you are not using a [`*.workers.dev`](https://workers.dev) subdomain. +- `route` not inherited optional -* `routes` not inherited optional + - A route, specified by URL pattern, on your zone that you would like to run your Worker on.
`route = "http://example.com/*"`. A `route` OR `routes` key is only required if you are not using a [`*.workers.dev`](https://workers.dev) subdomain. - * A list of routes you would like to use your Worker on. These follow exactly the same rules a `route`, but you can specify a list of them.
`routes = ["http://example.com/hello", "http://example.com/goodbye"]`. A `route` OR `routes` key is only required if you are not using a `*.workers.dev` subdomain. +- `routes` not inherited optional -* `webpack_config` inherited optional + - A list of routes you would like to use your Worker on. These follow exactly the same rules a `route`, but you can specify a list of them.
`routes = ["http://example.com/hello", "http://example.com/goodbye"]`. A `route` OR `routes` key is only required if you are not using a `*.workers.dev` subdomain. - * This is the path to a custom webpack configuration file for your Worker. You must specify this field to use a custom webpack configuration, otherwise Wrangler will use a default configuration for you. Refer to the [Wrangler webpack page](/workers/wrangler/migration/v1-to-v2/eject-webpack/) for more information. +- `webpack_config` inherited optional -* `vars` not inherited optional + - This is the path to a custom webpack configuration file for your Worker. You must specify this field to use a custom webpack configuration, otherwise Wrangler will use a default configuration for you. Refer to the [Wrangler webpack page](/workers/wrangler/migration/v1-to-v2/eject-webpack/) for more information. - * An object containing text variables that can be directly accessed in a Worker script. +- `vars` not inherited optional -* `kv_namespaces` not inherited optional + - An object containing text variables that can be directly accessed in a Worker script. - * These specify any [Workers KV](#kv_namespaces) Namespaces you want to access from inside your Worker. +- `kv_namespaces` not inherited optional -* `site` inherited optional + - These specify any [Workers KV](#kv_namespaces) Namespaces you want to access from inside your Worker. - * Determines the local folder to upload and serve from a Worker. +- `site` inherited optional -* `dev` not inherited optional + - Determines the local folder to upload and serve from a Worker. - * Arguments for `wrangler dev` that configure local server. +- `dev` not inherited optional -* `triggers` inherited optional + - Arguments for `wrangler dev` that configure local server. - * Configures cron triggers for running a Worker on a schedule. +- `triggers` inherited optional -* `usage_model` inherited optional + - Configures cron triggers for running a Worker on a schedule. - * Specifies the [Usage Model](/workers/platform/pricing/#workers) for your Worker. There are two options - [`bundled`](/workers/platform/limits/#worker-limits) and [`unbound`](/workers/platform/limits/#worker-limits). For newly created Workers, if the Usage Model is omitted it will be set to the [default Usage Model set on the account](https://dash.cloudflare.com/?account=workers/default-usage-model). For existing Workers, if the Usage Model is omitted, it will be set to the Usage Model configured in the dashboard for that Worker. +- `usage_model` inherited optional -* `build` top level optional - - * Configures a custom build step to be run by Wrangler when building your Worker. Refer to the [custom builds documentation](#build) for more details. + - Specifies the [Usage Model](/workers/platform/pricing/#workers) for your Worker. There are two options - [`bundled`](/workers/platform/limits/#worker-limits) and [`unbound`](/workers/platform/limits/#worker-limits). For newly created Workers, if the Usage Model is omitted it will be set to the [default Usage Model set on the account](https://dash.cloudflare.com/?account=workers/default-usage-model). For existing Workers, if the Usage Model is omitted, it will be set to the Usage Model configured in the dashboard for that Worker. +- `build` top level optional + - Configures a custom build step to be run by Wrangler when building your Worker. Refer to the [custom builds documentation](#build) for more details. ### vars @@ -192,8 +184,6 @@ The `vars` key defines a table of [environment variables](/workers/configuration Usage: - - ```toml @@ -217,8 +207,6 @@ console.log(BAR); Alternatively, you can define `vars` using an inline table format. This style should not include any new lines to be considered a valid TOML configuration: - - ```toml @@ -229,20 +217,16 @@ vars = { FOO = "some value", BAR = "some other string" } :::note - Secrets should be handled using the [`wrangler secret`](/workers/wrangler/commands/#secret) command. - ::: -### kv\_namespaces +### kv_namespaces `kv_namespaces` defines a list of KV namespace bindings for your Worker. Usage: - - ```toml @@ -256,8 +240,6 @@ kv_namespaces = [ Alternatively, you can define `kv namespaces` like so: - - ```toml @@ -285,30 +267,24 @@ let value = await FOO.get("keyname"); //=> the "0f2ac...e279" KV namespace ``` +- `binding` required + - The name of the global variable your code will reference. It will be provided as a [KV runtime instance](/kv/api/). -* `binding` required - - * The name of the global variable your code will reference. It will be provided as a [KV runtime instance](/kv/api/). - -* `id` required - - * The ID of the KV namespace that your `binding` should represent. Required for `wrangler publish`. - -* `preview_id` required +- `id` required - * The ID of the KV namespace that your `binding` should represent during `wrangler dev` or `wrangler preview`. Required for `wrangler dev` and `wrangler preview`. + - The ID of the KV namespace that your `binding` should represent. Required for `wrangler publish`. +- `preview_id` required + - The ID of the KV namespace that your `binding` should represent during `wrangler dev` or `wrangler preview`. Required for `wrangler dev` and `wrangler preview`. :::note - Creating your KV namespaces can be handled using Wrangler’s [KV Commands](/workers/wrangler/migration/v1-to-v2/wrangler-legacy/commands/#kv). You can also define your `kv_namespaces` using an [alternative TOML syntax](https://github.com/toml-lang/toml/blob/master/toml.md#user-content-table). - ::: ### site @@ -317,8 +293,6 @@ A [Workers Site](/workers/configuration/sites/start-from-scratch) generated with Usage: - - ```toml @@ -329,25 +303,21 @@ entry-point = "workers-site" +- `bucket` required + - The directory containing your static assets. It must be a path relative to your Wrangler file. Example: `bucket = "./public"` -* `bucket` required - - * The directory containing your static assets. It must be a path relative to your Wrangler file. Example: `bucket = "./public"` +- `entry-point` optional -* `entry-point` optional + - The location of your Worker script. The default location is `workers-site`. Example: `entry-point = "./workers-site"` - * The location of your Worker script. The default location is `workers-site`. Example: `entry-point = "./workers-site"` +- `include` optional -* `include` optional - - * An exclusive list of `.gitignore`-style patterns that match file or directory names from your `bucket` location. Only matched items will be uploaded. Example: `include = ["upload_dir"]` - -* `exclude` optional - - * A list of `.gitignore`-style patterns that match files or directories in your `bucket` that should be excluded from uploads. Example: `exclude = ["ignore_dir"]` + - An exclusive list of `.gitignore`-style patterns that match file or directory names from your `bucket` location. Only matched items will be uploaded. Example: `include = ["upload_dir"]` +- `exclude` optional + - A list of `.gitignore`-style patterns that match files or directories in your `bucket` that should be excluded from uploads. Example: `exclude = ["ignore_dir"]` You can also define your `site` using an [alternative TOML syntax](https://github.com/toml-lang/toml/blob/master/toml.md#user-content-inline-table). @@ -360,8 +330,6 @@ For exceptionally large pages, Workers Sites may not be ideal. There is a 25 MiB If you want to include only a certain set of files or directories in your `bucket`, add an `include` field to your `[site]` section of your Wrangler file: - - ```toml @@ -379,8 +347,6 @@ Wrangler will only upload files or directories matching the patterns in the `inc If you want to exclude files or directories in your `bucket`, add an `exclude` field to your `[site]` section of your Wrangler file: - - ```toml @@ -402,9 +368,9 @@ If you provide both `include` and `exclude` fields, the `include` field will be Wrangler will always ignore: -* `node_modules` -* Hidden files and directories -* Symlinks +- `node_modules` +- Hidden files and directories +- Symlinks #### More about include/exclude patterns @@ -422,8 +388,6 @@ A set of cron triggers used to call a Worker on a schedule. Usage: - - ```toml @@ -433,12 +397,8 @@ crons = ["0 0 * JAN-JUN FRI", "0 0 LW JUL-DEC *"] - - -* `crons` optional - * A set of [cron expressions](https://crontab.guru/), where each expression is a separate schedule to run the Worker on. - - +- `crons` optional + - A set of [cron expressions](https://crontab.guru/), where each expression is a separate schedule to run the Worker on. ### dev @@ -446,8 +406,6 @@ Arguments for `wrangler dev` can be configured here so you do not have to repeat Usage: - - ```toml @@ -458,25 +416,21 @@ local_protocol = "https" +- `ip` optional + - IP address for the local `wrangler dev` server to listen on, defaults to `127.0.0.1`. -* `ip` optional +- `port` optional - * IP address for the local `wrangler dev` server to listen on, defaults to `127.0.0.1`. + - Port for local `wrangler dev` server to listen on, defaults to `8787`. -* `port` optional +- `local_protocol` optional - * Port for local `wrangler dev` server to listen on, defaults to `8787`. - -* `local_protocol` optional - - * Protocol that local `wrangler dev` server listen to requests on, defaults to `http`. - -* `upstream_protocol` optional - - * Protocol that `wrangler dev` forwards requests on, defaults to `https`. + - Protocol that local `wrangler dev` server listen to requests on, defaults to `http`. +- `upstream_protocol` optional + - Protocol that `wrangler dev` forwards requests on, defaults to `https`. ### build @@ -494,14 +448,12 @@ This section is for customizing Workers with the `service-worker` format. These ```js addEventListener("fetch", (event) => { - event.respondWith(new Response("I'm a service Worker!")); + event.respondWith(new Response("I'm a service Worker!")); }); ``` Usage: - - ```toml @@ -516,38 +468,28 @@ format = "service-worker" ##### `[build]` +- `command` optional + - The command used to build your Worker. On Linux and macOS, the command is executed in the `sh` shell and the `cmd` shell for Windows. The `&&` and `||` shell operators may be used. -* `command` optional - - * The command used to build your Worker. On Linux and macOS, the command is executed in the `sh` shell and the `cmd` shell for Windows. The `&&` and `||` shell operators may be used. - -* `cwd` optional - - * The working directory for commands, defaults to the project root directory. - -* `watch_dir` optional +- `cwd` optional - * The directory to watch for changes while using `wrangler dev`, defaults to the `src` relative to the project root directory. + - The working directory for commands, defaults to the project root directory. +- `watch_dir` optional + - The directory to watch for changes while using `wrangler dev`, defaults to the `src` relative to the project root directory. ##### `[build.upload]` +- `format` required - -* `format` required - - * The format of the Worker script, must be `"service-worker"`. - - + - The format of the Worker script, must be `"service-worker"`. :::note - Ensure the `main` field in your `package.json` references the Worker you want to publish. - ::: #### Modules @@ -560,10 +502,8 @@ Modules receive all bindings (KV Namespaces, Environment Variables, and Secrets) :::note - Refer to the [`fetch()` handler documentation](/workers/runtime-apis/handlers/fetch) to learn more about the differences between the Service Worker and Module worker formats. - ::: An uploaded module may `import` other uploaded ES Modules. If using the CommonJS format, you may `require` other uploaded CommonJS modules. @@ -572,21 +512,19 @@ An uploaded module may `import` other uploaded ES Modules. If using the CommonJS import html from "./index.html"; export default { - // * request is the same as `event.request` from the service worker format - // * waitUntil() and passThroughOnException() are accessible from `ctx` instead of `event` from the service worker format - // * env is where bindings like KV namespaces, Durable Object namespaces, Config variables, and Secrets - // are exposed, instead of them being placed in global scope. - async fetch(request, env, ctx) { - const headers = { "Content-Type": "text/html;charset=UTF-8" }; - return new Response(html, { headers }); - }, + // * request is the same as `event.request` from the service worker format + // * waitUntil() and passThroughOnException() are accessible from `ctx` instead of `event` from the service worker format + // * env is where bindings like KV namespaces, Durable Object namespaces, Config variables, and Secrets + // are exposed, instead of them being placed in global scope. + async fetch(request, env, ctx) { + const headers = { "Content-Type": "text/html;charset=UTF-8" }; + return new Response(html, { headers }); + }, }; ``` To create a Workers project using Wrangler and Modules, add a `[build]` section: - - ```toml @@ -602,56 +540,46 @@ main = "./worker.mjs" ##### `[build]` +- `command` optional + - The command used to build your Worker. On Linux and macOS system, the command is executed in the `sh` shell and the `cmd` shell for Windows. The `&&` and `||` shell operators may be used. -* `command` optional +- `cwd` optional - * The command used to build your Worker. On Linux and macOS system, the command is executed in the `sh` shell and the `cmd` shell for Windows. The `&&` and `||` shell operators may be used. - -* `cwd` optional - - * The working directory for commands, defaults to the project root directory. - -* `watch_dir` optional - - * The directory to watch for changes while using `wrangler dev`, defaults to the `src` relative to the project root directory. + - The working directory for commands, defaults to the project root directory. +- `watch_dir` optional + - The directory to watch for changes while using `wrangler dev`, defaults to the `src` relative to the project root directory. ##### `[build.upload]` +- `format` required + - The format of the Workers script, must be `"modules"`. -* `format` required - - * The format of the Workers script, must be `"modules"`. +- `dir` optional -* `dir` optional + - The directory you wish to upload your modules from, defaults to the `dist` relative to the project root directory. - * The directory you wish to upload your modules from, defaults to the `dist` relative to the project root directory. +- `main` required -* `main` required - - * The relative path of the main module from `dir`, including the `./` prefix. The main module must be an ES module. For projects with a build script, this usually refers to the output of your JavaScript bundler. + - The relative path of the main module from `dir`, including the `./` prefix. The main module must be an ES module. For projects with a build script, this usually refers to the output of your JavaScript bundler. :::note - If your project is written using CommonJS modules, you will need to re-export your handlers and Durable Object classes using an ES module shim. Refer to the [modules-webpack-commonjs](https://github.com/cloudflare/modules-webpack-commonjs) template as an example. - ::: -* `rules` optional +- `rules` optional - * An ordered list of rules that define which modules to import, and what type to import them as. + - An ordered list of rules that define which modules to import, and what type to import them as. You will need to specify rules to use Text, Data, and CompiledWasm modules, or when you wish to have a `.js` file be treated as an `ESModule` instead of `CommonJS`. Defaults: - - ```toml @@ -673,28 +601,24 @@ globs = ["**/*.js", "**/*.cjs"] -* `type` required +- `type` required - * The module type, see the table below for acceptable options: + - The module type, see the table below for acceptable options: -* `globs` required +- `globs` required - * UNIX-style [glob rules](https://docs.rs/globset/0.4.6/globset/#syntax) that are used to determine the module type to use for a given file in `dir`. Globs are matched against the module's relative path from `build.upload.dir` without the `./` prefix. Rules are evaluated in order, starting at the top. + - UNIX-style [glob rules](https://docs.rs/globset/0.4.6/globset/#syntax) that are used to determine the module type to use for a given file in `dir`. Globs are matched against the module's relative path from `build.upload.dir` without the `./` prefix. Rules are evaluated in order, starting at the top. -* `fallthrough` optional +- `fallthrough` optional - * This option allows further rules for this module type to be considered if set to true. If not specified or set to false, further rules for this module type will be ignored. + - This option allows further rules for this module type to be considered if set to true. If not specified or set to false, further rules for this module type will be ignored. - - -*** +--- ## Example To illustrate how these levels are applied, here is a Wrangler file using multiple environments: - - ```toml diff --git a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/index.mdx b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/index.mdx index 944d69832e5395d..5119decc2d58f7e 100644 --- a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/index.mdx +++ b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/index.mdx @@ -4,10 +4,10 @@ pcx_content_type: navigation head: - tag: title content: Wrangler v1 (legacy) - +noindex: true --- -import { DirectoryListing, Render } from "~/components" +import { DirectoryListing, Render } from "~/components"; The following documentation applied to Wrangler v1 usage. diff --git a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/install-update.mdx b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/install-update.mdx index 9b2370a4542722f..a2403f362b779d9 100644 --- a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/install-update.mdx +++ b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/install-update.mdx @@ -3,6 +3,8 @@ pcx_content_type: how-to title: Install / Update sidebar: order: 1 + +noindex: true --- import { Render } from "~/components"; diff --git a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/webpack.mdx b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/webpack.mdx index c6b0690e8b4d5fa..cda45b69cf55621 100644 --- a/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/webpack.mdx +++ b/src/content/docs/workers/wrangler/migration/v1-to-v2/wrangler-legacy/webpack.mdx @@ -4,10 +4,10 @@ title: Webpack description: Learn how to migrate from Wrangler v1 to v2 using webpack. This guide covers configuration, custom builds, and compatibility for Cloudflare Workers. sidebar: order: 5 - +noindex: true --- -import { Render, WranglerConfig } from "~/components" +import { Render, WranglerConfig } from "~/components"; @@ -27,8 +27,8 @@ This is the default webpack configuration that Wrangler uses to build your Worke ```js module.exports = { - target: "webworker", - entry: "./index.js", // inferred from "main" in package.json + target: "webworker", + entry: "./index.js", // inferred from "main" in package.json }; ``` @@ -44,9 +44,9 @@ You can tell Wrangler to use a custom webpack configuration file by setting `web ```js module.exports = { - target: 'webworker', - entry: './index.js', - mode: 'production', + target: "webworker", + entry: "./index.js", + mode: "production", }; ``` @@ -66,8 +66,6 @@ webpack_config = "webpack.config.js" It is possible to use different webpack configuration files within different [Wrangler environments](/workers/wrangler/environments/). For example, the `"webpack.development.js"` configuration file is used during `wrangler dev` for development, but other, more production-ready configurations are used when building for the staging or production environments: - - ```toml @@ -90,18 +88,18 @@ webpack_config = "webpack.production.js" ```js module.exports = { - target: 'webworker', - devtool: 'cheap-module-source-map', // avoid "eval": Workers environment doesn’t allow it - entry: './index.js', - mode: 'development', + target: "webworker", + devtool: "cheap-module-source-map", // avoid "eval": Workers environment doesn’t allow it + entry: "./index.js", + mode: "development", }; ``` ```js module.exports = { - target: 'webworker', - entry: './index.js', - mode: 'production', + target: "webworker", + entry: "./index.js", + mode: "production", }; ``` @@ -126,10 +124,10 @@ The corresponding `webpack.config.js` file should look like this: ```js module.exports = { - context: __dirname, - target: 'webworker', - entry: './index.js', - mode: 'production', + context: __dirname, + target: "webworker", + entry: "./index.js", + mode: "production", }; ``` @@ -142,17 +140,17 @@ For example, you may want to replace the `URL` global class with the `url-polyfi ### Example with webpack plugin ```js null {1,7,8,9,10,11} -const webpack = require('webpack'); +const webpack = require("webpack"); module.exports = { - target: 'webworker', - entry: './index.js', - mode: 'production', - plugins: [ - new webpack.ProvidePlugin({ - URL: 'url-polyfill', - }), - ], + target: "webworker", + entry: "./index.js", + mode: "production", + plugins: [ + new webpack.ProvidePlugin({ + URL: "url-polyfill", + }), + ], }; ```