Add bundle.external configuration option for marking modules as external during bundling#12883
Add bundle.external configuration option for marking modules as external during bundling#12883dario-piotrowicz wants to merge 3 commits intomainfrom
bundle.external configuration option for marking modules as external during bundling#12883Conversation
🦋 Changeset detectedLatest commit: cee4718 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
✅ All changesets look good |
This comment was marked as outdated.
This comment was marked as outdated.
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
wrangler
commit: |
…xternal during bundling
1e73e66 to
633a474
Compare
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
.changeset/large-coins-open.md
Outdated
| "wrangler": minor | ||
| --- | ||
|
|
||
| Add `bundling_external` configuration option for marking modules as external during bundling |
There was a problem hiding this comment.
Sorry for the bike-shedding, but I wonder if external_imports might be a bit clearer here? It may make it more obvious what the array contains. 😄
There was a problem hiding this comment.
mh... I would really keep bundling in the name though... no? just to make it extra clear that this is related to bundling 🤔
I was also thinking... what if we added a bundling config object and in it the only field (for now at least) would be external_imports?
There was a problem hiding this comment.
Makes sense to me. In that case, I wonder if bundle.external would be a better fit, since it would read as a more explicit counterpart to no_bundle.
Then, if this area grows over time, we could potentially add things like bundle.minify and gradually move some of the current top-level config there and then deprecate the old names . Definitely not something this PR needs to solve, just thinking out loud about how this config might evolve.
There was a problem hiding this comment.
yeah that sounds like a potentially good plan to me 🙂
shall I just then turn bundling_external to bundle.external? 🙂
bundling_external configuration option for marking modules as external during bundlingbundle.external configuration option for marking modules as external during bundling
| if (config.bundle) { | ||
| logger.warn( | ||
| "`bundle` and `--no-bundle` can't be used together. Please choose the one that is most appropriate for your use case." | ||
| ); | ||
| } |
There was a problem hiding this comment.
🔴 config.bundle is always truthy, causing spurious warning when using --no-bundle
In deploy.ts:583, the check if (config.bundle) is always truthy because the default value for config.bundle is {} (set in packages/workers-utils/src/config/config.ts:384 and as the default in packages/workers-utils/src/config/validation.ts:1925). An empty object {} is truthy in JavaScript, so whenever --no-bundle is used, the warning "bundle and --no-bundle can't be used together" will always fire, even when the user has not configured any bundle.external entries. The check should be config.bundle?.external?.length (similar to the check in versions/upload.ts:506) to only warn when external modules are actually configured.
| if (config.bundle) { | |
| logger.warn( | |
| "`bundle` and `--no-bundle` can't be used together. Please choose the one that is most appropriate for your use case." | |
| ); | |
| } | |
| if (config.bundle?.external?.length) { | |
| logger.warn( | |
| "`bundle` and `--no-bundle` can't be used together. Please choose the one that is most appropriate for your use case." | |
| ); | |
| } |
Was this helpful? React with 👍 or 👎 to provide feedback.
| if (props.noBundle && minify) { | ||
| logger.warn( | ||
| "`--minify` and `--no-bundle` can't be used together. If you want to minify your Worker and disable Wrangler's bundling, please minify as part of your own bundling process." | ||
| ); | ||
| } | ||
|
|
||
| if (props.noBundle && config.bundle?.external?.length) { | ||
| logger.warn( | ||
| "`bundle.external` and `--no-bundle` can't be used together. If you want to exclude modules from your bundle and disable Wrangler's bundling, please handle external modules as part of your own bundling process." | ||
| ); | ||
| } |
There was a problem hiding this comment.
🟡 Redundant props.noBundle && checks inside already-guarded if (props.noBundle) block
In versions/upload.ts:500 and versions/upload.ts:506, the conditions props.noBundle && minify and props.noBundle && config.bundle?.external?.length redundantly re-check props.noBundle despite already being inside an if (props.noBundle) block. This is inconsistent with the equivalent code in deploy.ts:576-588 which does not have the redundant checks. While not a runtime bug (the logic is still correct), this is a copy-paste error that adds unnecessary noise.
| if (props.noBundle && minify) { | |
| logger.warn( | |
| "`--minify` and `--no-bundle` can't be used together. If you want to minify your Worker and disable Wrangler's bundling, please minify as part of your own bundling process." | |
| ); | |
| } | |
| if (props.noBundle && config.bundle?.external?.length) { | |
| logger.warn( | |
| "`bundle.external` and `--no-bundle` can't be used together. If you want to exclude modules from your bundle and disable Wrangler's bundling, please handle external modules as part of your own bundling process." | |
| ); | |
| } | |
| if (minify) { | |
| logger.warn( | |
| "`--minify` and `--no-bundle` can't be used together. If you want to minify your Worker and disable Wrangler's bundling, please minify as part of your own bundling process." | |
| ); | |
| } | |
| if (config.bundle?.external?.length) { | |
| logger.warn( | |
| "`bundle.external` and `--no-bundle` can't be used together. If you want to exclude modules from your bundle and disable Wrangler's bundling, please handle external modules as part of your own bundling process." | |
| ); | |
| } |
Was this helpful? React with 👍 or 👎 to provide feedback.
| if (config.bundle) { | ||
| logger.warn( | ||
| "`bundle` and `--no-bundle` can't be used together. Please choose the one that is most appropriate for your use case." | ||
| ); | ||
| } |
There was a problem hiding this comment.
🟡 Inconsistent no-bundle + bundle.external warning messages between deploy.ts and versions/upload.ts
In deploy.ts:584-586, the warning when --no-bundle and bundle are used together says "bundle and --no-bundle can't be used together" with a generic message. In versions/upload.ts:507-508, the equivalent warning says "bundle.external and --no-bundle can't be used together" with a more specific message about handling external modules. The deploy.ts version checks config.bundle (which is always truthy as noted in BUG-0001) while versions/upload.ts correctly checks config.bundle?.external?.length. The behavior is inconsistent between the two code paths for the same feature.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Closing in favor of #12931, thanks a bunch @edmundhung for reviewing the PR anyways 🙏 |
Fixes #7095
This PR adds a
bundle.externalwrangler option to make packages as external. It also improves the esbuild error message to mention this new option oraliasas a way to fix imports that failed to be resolved.(Note: the screenshot is slightly outdated,
bundling_externalhas been updated tobundle.external)A picture of a cute animal (not mandatory, but encouraged)