Code splitting across reexports using symbol data by splitting dependencies #8432
Conversation
| if ( | ||
| node.type === 'dependency' && | ||
| node.value.specifier === '@parcel/service-worker' | ||
| node.value.specifier === '@parcel/service-worker' && | ||
| !bundleGraph.isDependencySkipped(node.value) |
There was a problem hiding this comment.
This was needed because there are now two such dependencies, one of the being excluded.
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. |
FYI - I have this change patched in to our very large app for a few days now without build issues, and no runtime issues we're yet aware of (dog-fooding is currently limited for the Parcel builds). It's provided an improvement in runtime performance (hard to quantify as we had a workaround in place rewriting imports with a transform, but it's provided a further 10% improvement over the workaround - I think we're roughly at 30-40% improvement over the baseline we had). |
Closes #7392
Symbol propagation already does the traversals anyway, so now it just always tracks for each symbol in a dependency, what that symbol should resolve to.
So for each used symbol, it now says where that symbol should resolve to. This is not exectly the same as
getSymbolResolutionthough, as it stops at non-sideeffect-free assets (whilegetSymbolResolutiondoes resolve through them).This information is then used in
BundleGraph.fromAssetGraphto split up dependencies to be per symbol (and point them at the resolved asset according to the previous analysis). The old dependency is kept in case some transformer used its placeholder. This changes the execution order because the old dependency is replaced withdep.usedSymbolsUp.map(... => new Dependency(...))so the arbitrary (sorted alphabetically) order of the symbols is used for this.Since it's possible to rename symbols via reexports, I've had to add an additional map to the dependency node, e.g. a dependency to a side-effect-free asset that doesexport {foo as bar} from "y";would then be rewritten to point directly toyinstead, and thesymbolTargetmap then hasfoo -> barwhich is applied transparently inbundleGraph.getUsedSymbolsandbundleGraph.getSymbols(which I think is a better solution compared to mutating the actual DependencyValue symbols entry).dependency.symbolTarget