🐰 Pull Request

This PR address experimental bundler issues with CompiledCss extraction enabled.

Problem 1 was that upon internalization of async bundles, we allowed for orphans to be left behind (of type change bundles) and thus were deleted from the graph.

Solution: This PR adds the function attachOrphans which makes sure that any children of an async bundle in the bundleGraph (these will only be non async code split point bundles) are then connected to whatever parent the async bundle was internalized into.

I've also moved the merge bundles of type change step to be after internalization, so that we don't need to remerge any type change bundles after internalization, which could add a lot of extra work.

Problem 2 arose after Issue 1 was fixed. We had been processing type change bundles within the parallel request limit code. This would've been okay, since we only merge back / alter bundles with source bundles. However, when a reused bundle (an async bundle with source bundles) gets merged back, we know it may have children, so we propagate the reused bundle's source bundles to its children and attach it to the new parent. This is because we assumed the children of an async bundle at that point would only be shared bundles.
But that is not the case.

Solution: Instead, upon merging back a reused bundle, its child of a different type must be either connected to the new parent OR its assets merged into the new parent's already existing bundle of that type.

💻 Examples

The Grey Graphs below are the "bare bones" bundleGraph we use in the experimental bundler, which display only bundles loaded in parallel and their children. So all async bundles are all on the same "level" (i.e. connected to root) and their children are parallel or type change bundles, which are connected to what pulls them in.

We maintain sync relationships and async referencing relationships in supplementary graphs which are not shown but the drawings display these relationships.

INTERNALIZATION ORPHAN BUG

First, here is a visual representation of the dependencies each file has.

So, given that setup, we know foo.js should be internalized into index.js. But foo.js has two "children". One is displayed in the graph below as it is a type change and the other is bazz.js which is an async bundle but is referenced by or "pulled in" by foo.

We need to make sure we patch up these would-be orphans. So, connect them to the parent. In the bazz.js case we change around our supplementary graphs instead (i.e. remove foo async connections and patch them up)

Type bundles must be merged per bundleGroups so this is why I moved STEP MERGE BUNDLES to occur later, so that we don't need to re-merge.

Finally, assets are placed into bundles.

PARALLEL LIMIT TYPE CHANGE BUG

First, heres a representation of the dependencies each asset has on others

So, given that setup, we see that bar.js and foo.js become their own bundles as they're code split points. (Async relationship). Notice in the graph above, that they share some assets synchronously. Normally, we can create a shared bundle here, which will be a child to both and have a property sourcebundles to reference them. However, in the experimentalbundler, if a bundle requires the total sum of a bundle including it's main Asset Entry (which is foo.js in this case) we simply "reuse" the existing bundle. This creates a hybrid bundle that has a mainEntryAsset, and sourceBundles.

The Graph below shows foo.js as a reused bundle. It has a source bundle, bar.js but also remember it is originally referenced by indexcss.js by async relationship.

Now, that graph above would be fine, since even though you see two bundles of type css, they're in different bundleGroups. But we have to uphold parallel request limits which has special rules for reused bundles. The current rules are:

1. Do not fully delete a merged back reused bundle, because it has something originally pulling it in (indexcss.js)
2. Place the merged back bundle's assets into the source bundles (a.js, b.js, and foo.js are placed into bar.js)
3. Connect the children to source bundles ( styles.css )
4. If the child is a shared bundle, update its source bundles. If not, do not.
5. If the child is a type change bundle, you must either connect it to the new parent or merge it into an existing bundle of that type in that bundleGroup (styles.css asset is duplicated and placed into c.css bundle)

✔️ PR Todo

• Added/updated unit tests for this change
• Tested on large app : Fixed build error
• Test runtime (on large app)
• Test runtime without compiledCSS enabled on large app
• Included links to related issues/PRs
• Add diagrams
• Add description
• Flow
• Investigate react spectrum failure
• Add test case for react spectrum failure
• Update hasEdge with @mattcompiles changes