Regression: Cannot find module (for @babel/runtime/helpers/interopRequireDefault)

[lgarron]

🐛 bug report

Building our project with the latest Parcel nightly results in the following:

index.ba372ea6.js:61 Uncaught Error: Cannot find module '4ttVj'
    at newRequire (index.ba372ea6.js:61)
    at newRequire (index.4dfb00e8.js:53)
    at newRequire (index.6313b7ff.js:53)
    at newRequire (index.59a34dfe.js:53)
    at newRequire (index.f00b8b70.js:53)
    at newRequire (puzzle-geometry.67287cb1.js:53)
    at newRequire (puzzle-geometry.67287cb1.js:45)
    at localRequire (puzzle-geometry.67287cb1.js:83)
    at Object.4vUwq.@babel/runtime/helpers/interopRequireDefault (puzzle-geometry.67287cb1.js:270)
    at newRequire (puzzle-geometry.67287cb1.js:71)

Per another portion of the build, 4ttVj corresponds to:

"@babel/runtime/helpers/interopRequireDefault":"4ttVj"

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

https://github.com/cubing/cubing.js/blob/45d61a4ed69d7e710c2b601a6e164a994619b449/package.json

Repro:

# Check out the project
git clone https://github.com/lgarron/parcel-6192/
cd parcel-6192
git checkout 45d61a4ed69d7e710c2b601a6e164a994619b449
npm install

# Build
make parcel-build-for-experiments-cubing-net

# Serve
mkdir -p serve
cd serve
ln -s ../dist/experiments.cubing.net/cubing.js/experiments-cubing-net ./cubing.js
python -m SimpleHTTPServer

# Example repro page
open http://localhost:8000/cubing.js/twizzle/index.html

Note that this is an issue specifically with parcel build. parcel serve handles the exact same page just fine:

make dev

open http://localhost:3333/twizzle/index.html?puzzle=3x3x3

🤔 Expected Behavior

The page loads and shows puzzles:

😯 Current Behavior

The page runs into the error documented above:

💁 Possible Solution

I've tracked this down to the range between nightly 481 and nightly 485:

a4cf3e9...8fdb958

Of those, I think 3f1935a looks like the most likely to have caused this.

🔦 Context

I upgraded our project to the latest Parcel nightly for some other bug fixes. I later found out this broke our production deployment.

💻 Code Sample

https://github.com/cubing/cubing.js

🌍 Your Environment

Software	Version(s)
Parcel	2.0.0-nightly.643+3baf990a
Node	v15.12.0
npm/Yarn	7.6.3
Operating System	macOS 10.15.7

This happens across browsers.

[lgarron]

Of those, I think 3f1935a looks like the most likely to have caused this.

Turns out that this links to #5683. 😬

That bug is basically the same, except in the meantime I've followed this advice. That seems to have solved the problem for parcel serve, but it's a little disconcerting that that parcel build runs into problems that don't surface during development.

Feel free to close this if it turns out the be exactly same issue regardless.

Seeing as it's long enough that I've managed to lose track of older Parcel bugs I've filed and ended up retracing the same bisection, it would really help to have a better fix or at least a better error message. 🙏

[lgarron]

Any recommendations for what to do about this issue?

I've spent several hours trying to debug it, and I haven't found anything on our side to make it work.

Would it be best for us to revert to an older Parcel nightly for the foreseeable future?

[mischnic]

A small reproduction for this error would be great.

but it's a little disconcerting that that parcel build runs into problems that don't surface during development.

Shared bundles are disabled in development because determining which assets to put in to shared bundles is neither parallelized nor cached.

[lgarron]

A small reproduction for this error would be great.

I'll try, but I haven't had good luck with this in the past. :-(

Shared bundles are disabled in development because determining which assets to put in to shared bundles is neither parallelized nor cached.

is it possible to turn this off for production so that we can deploy safely?
Optimization isn't important at the moment.

[mischnic]

is it possible to turn this off for production so that we can deploy safely?

1. Try with --no-scope-hoist
2. Set minBundleSize to an absurdly high number: https://v2.parceljs.org/features/code-splitting/#shared-bundles

[lgarron]

I've almost got this down to a minimal repro: https://github.com/cubing/cubing.js/tree/parcel-6192

This is looking similar to #5118 (which is a bug for Parcel 1), but only triggered by bundle splitting in certain circumstances.

[lgarron]

Alright, I've reduced the repro to the following:

// src/alg/index.ts
export class Alg {
  readonly #repetition = null;
  constructor() {
    console.log(this.#repetition)
  }
}

import "./bulky-code"

// src/puzzle-geometry/index.ts
import { Alg } from "../alg";
class FaceNameSwizzler {
  public prefixFree: boolean = true;
}
console.log(FaceNameSwizzler, Alg)

// src/puzzles/index.ts
(async () => {
  console.log(await import("../puzzle-geometry"));
})();

// src/demo/alg.cubing.net/index.ts
import "../../cubing/puzzle-geometry";

// src/demo/robot/logs/index.ts
import "../../../cubing/alg";

// src/demo/robot/index.ts
import "../../cubing/puzzles";

Note that this still follows the advice from #5683 (comment) : every .ts entry file (those under src/demo) is unique to one inclusion in one corresponding .html file. Also, none of the the entry files import each other.

Please let me know if it would help to try to pinpoint things further. So far, it seems both the private and public fields as well as the async import are "load-bearing" for this bug.

---

EDIT: This has been moved to https://github.com/lgarron/parcel-6192/
See the initial post for updated repro steps.

[lgarron]

Thanks for the suggestions!

1. Try with --no-scope-hoist

We already have this enabled (to work around another bug, don't recall which one).

2. Set minBundleSize to an absurdly high number: https://v2.parceljs.org/features/code-splitting/#shared-bundles

Unfortunately, that doesn't seem to work. :-(

[lgarron]

Alright, I've reduced the repro to the following:

I've now moved this to https://github.com/lgarron/parcel-6192/

[mischnic]

It seems to happen also without modern class features: https://github.com/mischnic/parcel-issue-6192

So indeed similar to #5683

[mischnic]

With my repro,

• http://localhost:8000/alg.cubing.net/index.html fails because of Regression: Uncaught error: Cannot find module #5683 (comment). Swapping the order of script tags to shared bundles makes it work

• http://localhost:8000/robot/index.html fails with Could not resolve bundle with id 5OFzW Not sure why yet because it isn't listed in the the bundle registry