A draft conditional bundling approach #9661
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
↪️ Pull Request
This is a partially working draft implementation of an approach for a specific type of conditional bundling that is designed for feature flags more than any other more general purpose "conditions".
The intention is that the end-user will not pay the download cost for code they will not execute because they do not have the feature flag enabled.
What it does
As a developer, you write:
At runtime this will give you either the
Component
export fromNewComponent
orOldComponent
. It is important to note that this is a synchronous import, it does not require a "tick" to return the module.How it works
Currently we're essentially using the same underlying mechanisms as for dynamic imports to have Parcel produce new bundle groups for each of the "true" and "false" arms of the condition.
The
importCond
is replaced with aparcelRequire
to a runtime asset that looks like:It is up to the server to have:
my.feature.flag
feature flag and rendered the<script />
tag(s) for the correct bundle group (I mean, realistically it could render both bundle groups but that would negate the whole point of avoiding shipping the code)<script />
that setswindow.__conditions = { 'my.feature.flag' : (true|false) }
for the runtime to use.There is a Reporter that is currently in my test repo, that calls
unstable_getConditionalBundleMapping
in order to get the information needed for a server manifest.What's missing from the draft implementation
ScopeHoistingPackager
to ensure the dependency rewrites work correctlyWhat I'm looking for
As this is all behind a feature flag, I'd still be keen on getting it merged at some point in order to allow us to experiment with it internally. I'll address some of the FIXMEs first though (mostly the hacks in the packager).
In the spirit of trunk based development, it would also be good to merge this even if it's not complete (see the "What's missing") rather than having a long running branch, so a focus on any blockers to that would be good (currently with the feature flag disabled there's mostly no impact except to some types, so it's a pretty safe change)
💻 Examples
🚨 Test instructions
✔️ PR Todo