-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Do not merge isolated bundles in experimental bundler #8566
Conversation
Benchmark ResultsKitchen Sink ✅
Timings
Cold BundlesNo bundle changes detected. Cached BundlesNo bundle changes detected. React HackerNews 🚨
Timings
Cold BundlesNo bundles found, this is probably a failed build... Cached BundlesNo bundles found, this is probably a failed build... AtlasKit Editor 🚨
Timings
Cold BundlesNo bundles found, this is probably a failed build... Cached BundlesNo bundles found, this is probably a failed build... Three.js ✅
Timings
Cold BundlesNo bundle changes detected. Cached BundlesNo bundle changes detected. |
@@ -670,8 +672,9 @@ function createIdealGraph( | |||
); | |||
if ( | |||
bundle !== 'root' && | |||
bundle.bundleBehavior !== 'inline' && | |||
!bundle.env.isIsolated() | |||
bundle.bundleBehavior == null && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is what caused the test change, where a bundle was previously internalized and now isn't. I think in the general case, however, that isolated bundles should not be reachable.
// Store Type-Change bundles for later since we need to know ALL bundlegroups they are part of to reduce/combine them | ||
typeChangeIds.add(bundleId); | ||
if (parentAsset.type !== childAsset.type) { | ||
typeChangeIds.add(bundleId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Speaking of fixes, I notice in the default bundler we maintain bundleByType
, which not only holds bundles created via type change, but also all others (lazy/ parallel etc). It looks like that is how we determine where we can merge a type change bundle.
In experimental, we only attempt to merge type change with type change.... does this mean we're not merging as many bundles as we could in experimental ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should not merge parallel/lazy bundles, because the transformer that created those dependencies might not expect it. For example, if you have two <script>
tags in an HTML page, those have parallel priority, but merging them would result in both scripts pointing to the same URL and (possibly?) executing twice.
typeChangeIds.add(bundleId); | ||
} | ||
} else { | ||
// Otherwise, merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is my mistake, but this comment doesn't make sense here anymore since we don't merge until later
This make handling of
bundleBehavior
more consistent, and fixes bundle merging logic with isolated bundles. In addition, bundles of different contexts should not be merged. This fixes the react spectrum site