Improve the handling of entry bundle collisions

[richardkmichael]

🐛 bug report

1. Bundle names collide under certain circumstances, but it is unclear to the user which asset(s) cause the problem, or why, or what to do to fix it. Suggestions would be helpful. I notice parcel > 2.8.3 had a recent commit to output asset names, which is an improvement. However, in a larger app, with many dynamic imports, or other conditional code paths, it would difficult to know what happened and how to deal with it.

2. Parcel appears to be failing to invalidate the cache when code changes.

Given a source tree which does not bundle on first run (no cache, etc.):

If the code is changed so that parcel can bundle it, and parcel writes a cache during that successful compilation, and the code change is then reverted (such that it should fail to bundle as it originally did), parcel will in fact succeed -- by virtue of the cache created during the previous successful build.

🎛 Configuration (.babelrc, package.json, cli command)

Out of the box parcel, no additional configuration.

🤔 Expected Behavior

Tell me exactly which assets are the problem, and why (dynamic import and where in the tree, etc.).

Ideally though, for some cases parcel would simply know what to do. The real-world code which caused this problem is much more complicated, although it does build with webpack 4 (as part of a create-react-app).

😯 Current Behavior

Parcel outputs an AssertionError and aborts.

💁 Possible Solution

Output enough information that I might be able to fix it.

Unsure how parcel could automatically handle this; I'm not sure what webpack is doing (but it does bundle).

🔦 Context

I am trying to move a create-react-app to Parcel without making any Parcel specific changes to the source.

In the app, which the code is slightly different, I was actually able to "solve" this problem by changing the export list of the module which is causing the problem, and consequently the import method as well. But, it took me quite a long time to understand what was happening whatsoever, because the error message was uninformative.

💻 Code Sample

Both issues are described in the README and src/index.js of a small re-pro project. I included Graphviz PNG dumps as well.

https://github.com/richardkmichael/parcel-repro

🌍 Your Environment

Software	Version(s)
Parcel	2.8.3
Node	16.19.0
npm/Yarn	8.19.3
Operating System	macOS 11.7.2

[mischnic]

Thank you for the detailed investigation and great reproduction!

---

cc @AGawrys this might be a bundling problem.

entry js imports main.css
         imports Foo/foo.css
         imports async import("Foo/index.js"), which imports Foo/foo.css

and AFAICT the last import from Foo/index.js to Foo/foo.css shouldn't do anything because it's available in the parent anyway. What it tries to do is make the entry bundle group contain a bundle with the entry JS, one bundle with main.css and one bundle with Foo/foo.css.

---

Regarding "Bug 2: Mis-use of cache / failed cache invalidation"

This actually happens because adding and removing that line is equivalent to this program

import './main.css';
import('./Foo');
import './Foo/foo.css';

(because the middle dependency is removed, and then added again, putting it last).
Which coincidentally builds fine for some reason.

[richardkmichael]

@mischnic Thank you for your patience and help on Discord. 👍 I determined the problem and created the re-pro fairly quickly after your suggestion.

[jondlm]

We are also running into this issue but with a possibly simpler case that doesn't involve async bundles.

I tried out @AGawrys's patch from #9023 and it fixed the problem for me 🎉. Hoping we can shepherd that one along.

→ Repro case

TL;DR:

package.json

...
  "source": [
    "src/a.js",
    "src/b.js"
  ],
...

src/a.js

import "./a.css";
import "./b.css";

src/b.js

// 💡 Oddly, uncommenting this line works around the bug
// import "./a.css";

import "./b.css";

src/a.css and src/b.css can be empty.

When I run parcel build I get the @parcel/namer-default: Bundle group cannot have more than one entry bundle of the same type error.