Bundling
By default, Wrangler bundles your Worker code using esbuild
↗. This means that Wrangler has built-in support for importing modules from npm ↗ defined in your package.json
. To review the exact code that Wrangler will upload to Cloudflare, run npx wrangler deploy --dry-run --outdir dist
, which will show your Worker code after Wrangler’s bundling.
Bundling your Worker code takes multiple modules and bundles them into one file. Sometimes, you might have modules that cannot be inlined directly into the bundle. For example, instead of bundling a Wasm file into your JavaScript Worker, you would want to upload the Wasm file as a separate module that can be imported at runtime. Wrangler supports this for the following file types:
.txt
.html
.bin
.wasm
and.wasm?module
Refer to Bundling configuration to customize these file types.
For example, with the following import, the variable data
will be a string containing the contents of example.html
:
This is also the basis of Wasm support with Wrangler. To use a Wasm module in a Worker developed with Wrangler, add the following to your Worker:
By setting find_additional_modules
to true
in your configuration file, Wrangler will traverse the file tree below base_dir
.
Any files that match the rules
you define will also be included as unbundled, external modules in the deployed Worker.
This approach is useful for supporting lazy loading of large or dynamically imported JavaScript files:
- Normally, a large lazy-imported file (for example,
await import("./large-dep.mjs")
) would be bundled directly into your entrypoint, reducing the effectiveness of the lazy loading. If matching rule is added torules
, then this file would only be loaded and executed at runtime when it is actually imported. - Previously, variable based dynamic imports (for example,
await import(`./lang/${language}.mjs`)
) would always fail at runtime because Wrangler had no way of knowing which modules to include in the upload. Providing a rule that matches all these files, such as{ type = "EsModule", globs = ["./land/**/*.mjs"], fallthrough = true }
, will ensure this module is available at runtime. - “Partial bundling” is supported when
find_additional_modules
istrue
, and a source file matches one of the configuredrules
, since Wrangler will then treat it as “external” and not try to bundle it into the entry-point file.
Wrangler respects the conditional exports
field ↗ in package.json
. This allows developers to implement isomorphic libraries that have different implementations depending on the JavaScript runtime they are running in. When bundling, Wrangler will try to load the workerd
key ↗. Refer to the Wrangler repository for an example isomorphic package ↗.
If your build tooling already produces build artifacts suitable for direct deployment to Cloudflare, you can opt out of bundling by using the --no-bundle
command line flag: npx wrangler deploy --no-bundle
. If you opt out of bundling, Wrangler will not process your code and some features introduced by Wrangler bundling (for example minification, and polyfills injection) will not be available.
Use Custom Builds to customize what Wrangler will bundle and upload to the Cloudflare global network when you use wrangler dev
and wrangler deploy
.