-
Notifications
You must be signed in to change notification settings - Fork 10.4k
add Wrangler 'find_additional_modules' documentation #17524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
8d4f0f5
05b1503
5ab86b5
b5ab3d9
c7a0e61
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,24 +3,28 @@ pcx_content_type: configuration | |
| title: Bundling | ||
| head: [] | ||
| description: Review Wrangler's default bundling. | ||
|
|
||
| --- | ||
|
|
||
| By default, Wrangler bundles your Worker code using [`esbuild`](https://esbuild.github.io/). This means that Wrangler has built-in support for importing modules from [npm](https://www.npmjs.com/) 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. | ||
|
|
||
| :::note | ||
|
|
||
| We recommend using Wrangler's inbuilt bundling, but we understand there are cases where you will need more flexibility. We have built an escape hatch in the form of [Custom Builds](/workers/wrangler/custom-builds/), which lets you run your own build before Wrangler's built-in one. | ||
| Wrangler's inbuilt bundling usually provides the best experience, but we understand there are cases where you will need more flexibility. | ||
| You can provide `rules` and set `find_additional_modules` in your configuration to control which files are included in the deployed Worker but not bundled into the entry-point file. | ||
| Furthermore, we have an escape hatch in the form of [Custom Builds](/workers/wrangler/custom-builds/), which lets you run your own build before Wrangler's built-in one. | ||
petebacondarwin marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ::: | ||
|
|
||
| ## Files which will not be bundled | ||
| ## Including non-JavaScript modules | ||
|
|
||
| Bundling your Worker code takes multiple modules and bundles them into one. Sometimes, you might have modules that should not 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: | ||
| 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. | ||
petebacondarwin marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Wrangler supports this for the following file types: | ||
|
|
||
| * `.txt` | ||
| * `.html` | ||
| * `.bin` | ||
| * `.wasm` and `.wasm?module` | ||
| - `.txt` | ||
| - `.html` | ||
| - `.bin` | ||
| - `.wasm` and `.wasm?module` | ||
|
|
||
| Refer to [Bundling configuration](/workers/wrangler/configuration/#bundling) to customize these file types. | ||
|
|
||
|
|
@@ -37,17 +41,30 @@ import wasm from "./example.wasm"; // Where `example.wasm` is a file in your loc | |
| const instance = await WebAssembly.instantiate(wasm); // Instantiate Wasm modules in global scope, not within the fetch() handler | ||
|
|
||
| export default { | ||
| fetch(request) { | ||
| const result = instance.exports.exported_func(); | ||
| }, | ||
| fetch(request) { | ||
| const result = instance.exports.exported_func(); | ||
| }, | ||
| }; | ||
| ``` | ||
|
|
||
| :::caution | ||
|
|
||
| Cloudflare Workers does not support `WebAssembly.instantiateStreaming()`. | ||
| Cloudflare Workers does not support `WebAssembly.instantiateStreaming()`. | ||
| ::: | ||
|
|
||
| ## Find additional modules | ||
|
|
||
| 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even if you upload these as separate modules, don't we still have an issue? Or am I misunderstanding the problem there? cc @jasnell
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is definitely still a cost, since as I understand it, we do parse all modules at start up. The main difference, unless I am mistaken is that we don't execute the code in the lazy module until it is imported. |
||
| If matching rule is added to `rules`, then this file would only be loaded and executed at runtime when it is actually imported. | ||
petebacondarwin marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - 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. | ||
petebacondarwin marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| 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` is `true`, and a source file matches one of the configured `rules`, since Wrangler will then treat it as "external" and not try to bundle it into the entry-point file. | ||
|
|
||
| ## Conditional exports | ||
|
|
||
| Wrangler respects the [conditional `exports` field](https://nodejs.org/api/packages.html#conditional-exports) 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](https://runtime-keys.proposal.wintercg.org/#workerd). Refer to the Wrangler repository for [an example isomorphic package](https://github.com/cloudflare/workers-sdk/tree/main/fixtures/isomorphic-random-example). | ||
|
|
@@ -56,7 +73,7 @@ Wrangler respects the [conditional `exports` field](https://nodejs.org/api/packa | |
|
|
||
| :::caution | ||
|
|
||
| Disabling bundling is not recommended in most scenarios. Use this option only when deploying code pre-processed by other tooling. | ||
| Disabling bundling is not recommended in most scenarios. Use this option only when deploying code pre-processed by other tooling. | ||
| ::: | ||
|
|
||
| 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. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.