parcel
parcel copied to clipboard
parcel-bundler
Regression: `Uncaught error: Cannot find module`
I'm sorry for submitting such a general report without a small repro case. But this bug has already cost me a lot of time, and I'm very much at a loss for how to deal with it. I thought I'd file what I could, though.
🐛 bug report
Check out the following:
- Repo: https://github.com/cubing/cubing.js
- Commit: 3ff0968e92a46d14c2a1dad4f18080b6313f3949
Run:
npm install
make clean dev
Then visit http://localhost:3333/twisty/twisty-player.html and check the browser console.
See https://www.youtube.com/watch?v=PXkfFrLHS6o for an example of a successful build (beginning of video) and 8:32 for a failure.
To avoid the behaviour:
npm install [email protected] # no bug
rm -rf ./node_modules/ ; npm install; make clean dev
To cause the behaviour (sometimes):
npm install [email protected] # bug
rm -rf ./node_modules/ ; npm install; make clean dev
(Parcel nightly versions 482/483/484 do not exist.)
🤔 Expected Behavior
No error. The page loads, shows a Rubik's Cube, and a table for some options.
😯 Current Behavior
Sometimes (the vast majority of the time, maybe 90%?) after running npm install from scratch, the following error appears:
Uncaught Error: Cannot file module '2du48'.
This seems to correspond to ./dom/viewers/Twisty3DCanvas. It seems clear that there's an issue with the loading graph somehow related to this file, starting in [email protected].
See https://garron.net/temp/cubing-js-parcel-2021-01-18.zip for the state of the cache folder when this occurs.
Sometimes after running npm install (maybe 10% of the time?), however, there is no error. As far as I can tell, the error doesn't occur until the next time I delete node_modules and run npm install from scratch, which rolls the dice again.
💁 Possible Solution
No idea, I'm sorry. I've tried to dig into stack traces, but something is going wrong deep inside Parcel's module loading code and I can't debug it from inside my code.
I can't figure out how to map Parcel nightlies to Git commits, but correlating the version dates at https://www.npmjs.com/package/parcel with https://github.com/parcel-bundler/parcel/commits/v2?after=bdc45e49437b986934d3b1b0d8f6a4ecc292a2aa+34&branch=v2 suggests that this regression was introduced in this range:
https://github.com/parcel-bundler/parcel/compare/a4cf3e958ea1136b4829eb93615fba5328213471...f89e5ef87fcb58e6131475b5218f188cc231a1d9
🔦 Context
I was trying to debug a Parcel bug that is breaking our production build. I tried to update Parcel to the latest nightly 2.0.0-nightly.539 and was able to observe a bug in dev. After spending over 24 hours, I finally concluded that our production bug is not the same as the bug that was caused by upgrading to 2.0.0-nightly.539. I'm going to downgrade for now in order to debug the other issue, but I've filed this issue to document the one that happened due to the upgrade.
💻 Code Sample
See above.
🌍 Your Environment
| Software | Version(s) |
|---|---|
| Parcel | [email protected] and above (I bisected. 481 and lower do not exhibit this issue, 482/483/484 do not exist, 485 and above do exhibit the issue).) |
| Node | v15.4.0 |
| npm/Yarn | 6.14.11 |
| Operating System | macOS 10.15.7 as well as Big Sur (I can repro this issue on two different computers) |
Happens consistently for me with the minimal reproduction: https://github.com/mischnic/parcel-issue-5683
For dist/a.html, the script tags for the shared bundles are added in the wrong order.
I can't figure out how to map Parcel nightlies to Git commits
The hash is appended to the version field in the published tarball, you can see that for example here: https://unpkg.com/browse/[email protected]/package.json
I've bisected the commits, this is a regression of https://github.com/parcel-bundler/parcel/pull/5200.
A workaround is not using a file that is imported in some other place as a <script> directly.
So instead of this https://github.com/cubing/cubing.js/blob/afa6e5b9379e8b9549769ec0cea4615a87c80a73/src/demo/twisty/2d-ll-stickering.html#L7
adding a 2d-ll-stickering.js file with import "../../cubing/twisty/index.ts" (there might be other HTML files though)
A workaround is not using a file that is imported in some other place as a
<script>directly.So instead of this https://github.com/cubing/cubing.js/blob/afa6e5b9379e8b9549769ec0cea4615a87c80a73/src/demo/twisty/2d-ll-stickering.html#L7 adding a
2d-ll-stickering.jsfile withimport "../../cubing/twisty/index.ts"(there might be other HTML files though)
Thanks, that's very helpful! (I think that also explains some bugs I was seeing before.)
I've tried converting our project back to the Parcel v2 release candidate, and an error with this symptom ended up being a blocking issue again. :-/
VM566 2x2x2.kpuzzle.json_.a5d825d2.js:61 Uncaught Error: Cannot find module 'JacNc'
at newRequire (VM566 2x2x2.kpuzzle.json_.a5d825d2.js:61)
at newRequire (VM566 2x2x2.kpuzzle.json_.a5d825d2.js:45)
at localRequire (VM566 2x2x2.kpuzzle.json_.a5d825d2.js:83)
at Object.kmtFE.@parcel/transformer-js/src/esmodule-helpers.js (runtime-3acaea6fb4153fbf.js:377)
at newRequire (VM566 2x2x2.kpuzzle.json_.a5d825d2.js:71)
at VM566 2x2x2.kpuzzle.json_.a5d825d2.js:120
at VM566 2x2x2.kpuzzle.json_.a5d825d2.js:143
JacNc corresponds to:
"@parcel/transformer-js/src/esmodule-helpers.js":"JacNc"
I've tried converting our project back to the Parcel v2 release candidate, and an error with this symptom ended up being a blocking issue again. :-/
After some investigation, this seems to be the issue described in https://github.com/parcel-bundler/parcel/issues/4095
The same file was imported sync in one place and async in the other place, causing the sync import to break as described above. In this case, it's easy to switch the sync import to something else, but I'm rather sad that I'm already running into this issue again. 😭
@mischnic This is a consistent repro for me:
git clone https://github.com/cubing/cubing.js && cd cubing.js
git checkout parcel-yet-again # 867bce58e6cf8c9f5e7ca781bec3ba8948f422ab
git revert f56dcb8b6c002ef87cafe82a8da410d373c1b624
npm install
make build-search-worker
npx parcel src/sites/index.html
This is with Parcel 2.0.0-rc.0. :-(
npm 7.21.0 node v16.8.0 macOS 11.5.2 Chrome 92.0.4515.159
I am having the same issue with Cannot find module xxx, which corresponds to "@parcel/transformer-js/src/esmodule-helpers.js"
parcel 2.0.0 npm 8.1.0 node 16.13.0 macOS 11.6 Safari 15.0 (16612.1.29.41.4, 16612)
I just updated to Parcel 2.0.1 and still having the same issue. Is this a configuration option problem in our stack or is this a bug in Parcel?
I'm also experiencing the same issue and updating parcel to 2.0.1 didn't solve it.
parcel: 2.0.0-nightly.776
I have an even simpler repro: https://github.com/yume-chan/parcel-repro-5683
a.js and b.js each imports a different image file, so they are completely unrelated. When I include a.js before b.js in index.html, it works, then change the order, cannot find module.
Uncaught Error: Cannot find module 'ciiiV'
at newRequire (index.a28fffaf.js:61:19)
at newRequire (index.a28fffaf.js:45:18)
at localRequire (index.a28fffaf.js:84:35)
at Object.8FjLI../a.png (runtime-1f074fef905954b1.js:473:2)
at newRequire (index.a28fffaf.js:71:24)
at index.a28fffaf.js:122:5
at index.a28fffaf.js:145:3
It's related to build cache. If I clean the build cache, I can get the reversed behavior.
I think I'm suffering from a similar issue but not exactly this?
On 2.0.0-nightly.984+74fcc3fb I get index.f0bd8632.js:50 Uncaught Error: Cannot find module '43l7i', on 2.0.1 it works.
This issue is older than 2.0.1 so I guess it's something else. Will check if it's maybe cyclic imports…
Changing this in my entry index.html fixed it for me. Weird that I had no issues on 2.0.1.
diff --git a/app/public/index.html b/app/public/index.html
index 2b0e175da..1efda18df 100644
--- a/app/public/index.html
+++ b/app/public/index.html
@@ -47,6 +47,8 @@
To begin the development, run `npm start` or `yarn start`.
To create a production bundle, use `npm run build` or `yarn build`.
-->
- <script src="../src/index.tsx" type="module"></script>
+ <script type="module">
+ import "../src/index.tsx";
+ </script>
</body>
</html>
When changing the build target to ie 11 my builds fail with Uncaught Error: Cannot find module '2B7l9' :(
Cleaning build cache doesn't work.
Also hitting this on 2.3.2. Some level of complexity in the bundle graph seems to trigger it. The missing bundle is being generated, but the underlying js file is not being loaded client side. Tried fixing by removing scope hoisting and source mapping, but no luck.
Only occurs in build, not watch, since it's related to code splitting.
The underlying cause for us here appears to be related to the pragmaFrag /** @jsxImportSource @emotion/react */. @emotion/react allows you to pass down the css prop without explicitly including it in props. This works mostly fine, even with a tree of components that lack the above frag on some of the components that are doing the passthrough.
However, as soon as there is a tree with some mixture of frag and no frag, the above error occurs. Explicitly adding the frag to the component(s) missing it in the chain, even if they don't themselves use the css prop, fixes the problem.
Not enough time to come up with a minimal reproduction right now, but hopefully this is helpful to some of those hitting this bug and to the authors.
I have the same problem.
Uncaught Error: Cannot find module '622nD'
at a (index.cad93178.js:1:578)
at Object.<anonymous> (index.ts:2:1)
at a (index.cad93178.js:1:534)
at runtime-c3897e95e15efd7e.js:1:58
I had a similar error, after further debugging it seemed that I wasn't invoking the imported javascript function synchronously.
import '/src/scripts/myLib.ts'
window.myLib.init() // Causes the cannot find module error
The fix in my case was to call the init() func of myLib synchronously
Changed it to:
import('/src/scripts/myLib.ts').then(() => window.myLib.init())
and the error disappeared.
Using Parcel v2.4.0
The error reporting isn't so verbose, it can be that the fix is different in other cases. This was mine ☝️
PS: The above fix will change the script import from inline to dynamic. If you want to still keep the script inline, invoke init() function inside the myLib.ts instead
If Hot Module Reloading is not working, the problem may relate to the periods (.) of the directories name. We can try to get rid of them.
Consider changing the import statement from relative path to absolute path, and then change it back. This magically works for me.
import App from "./App";
import App from "/src/App"
<script type="module"> + import "../src/index.tsx"; + </script>
Works for me too... really strange behavior!
Changing this in my entry
index.htmlfixed it for me. Weird that I had no issues on 2.0.1.diff --git a/app/public/index.html b/app/public/index.html index 2b0e175da..1efda18df 100644 --- a/app/public/index.html +++ b/app/public/index.html @@ -47,6 +47,8 @@ To begin the development, run `npm start` or `yarn start`. To create a production bundle, use `npm run build` or `yarn build`. --> - <script src="../src/index.tsx" type="module"></script> + <script type="module"> + import "../src/index.tsx"; + </script> </body> </html>
@Aloento In my case I am using bootstrap.
If I do:
<body>
<script type="module" src="../js/scripts/home.js"></script>
<script type="module" src="../js/vendors/bootstrap.js"></script>
</body>
in this order, I get this strange error. But, if I change the imports order to:
<body>
<script type="module" src="../js/vendors/bootstrap.js"></script>
<script type="module" src="../js/scripts/home.js"></script>
</body>
(bootstrap first), the error is gone!
I observe similar issues with quite random "cannot find module", depending on a setup it affects different imports. Only on production builds. I'm trying to make a repro repo and so far no luck finding what could be a reason. Only happens so far on our most complex mono repo.
I believe my issue is related (if not duplicate). I'm happy to say I made a repro repo and also I found a workaround for all affected: bundler-experimental seems to be free of this bug.
Issue with repro repo: https://github.com/parcel-bundler/parcel/issues/8480
Workaround .parcelrc:
{
"extends": "@parcel/config-default",
"bundler": "@parcel/bundler-experimental"
}
I have the same error.
On the console, I see a bunch of warnings like these:
@parcel/transformer-js: Conditional or non-top-level `require()` call. This causes the resolved module and all dependencies to be wrapped.
@parcel/transformer-js: Unknown usage of CommonJS `module` object. This causes the module to be wrapped, and tree shaking to be disabled.
However, I do not have any conditional dependencies. Also, the "CommonJS module" errors refer to the parcel-internally generated JS code.
My stack uses:
- TypeScript
- React (written in .tsx)
- parcel
servemode
This solution worked for me: https://github.com/parcel-bundler/parcel/issues/5683#issuecomment-1022412113 This solution did not work for me: https://github.com/parcel-bundler/parcel/issues/5683#issuecomment-1249308888
I have encountered this error also.
I have a (AFAIK) straightforward repo and dev setup, purely for messing around with React and Node/TS. When I try npm run server with the index.js from either the dev or release targets specified i get the Cannot find module '???' error.
For the dev build it throws the following:
Error: Cannot find module 'express'
at newRequire (file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:61:19)
at newRequire (file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:45:18)
at localRequire (file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:84:35)
at Mo564.express (file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:159:16)
at newRequire (file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:71:24)
at localRequire (file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:84:35)
at 7nGH6../Server (file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:147:15)
at newRequire (file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:71:24)
at file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:122:5
at file:///mnt/Data/Repos/Demo-Project/build/dev/Server/index.js:145:3 {
code: 'MODULE_NOT_FOUND'
}
from this code:
...
})({"1FAFy":[function(require,module,exports) {
var parcelHelpers = require("@parcel/transformer-js/src/esmodule-helpers.js");
var _server = require("./Server");
var _serverDefault = parcelHelpers.interopDefault(_server);
let server = new (0, _serverDefault.default)();
server.start();
process.on("SIGTERM", async ()=>{
await server.stop();
});
},{"./Server":"5q1pD","@parcel/transformer-js/src/esmodule-helpers.js":"gsHjI"}],"5q1pD":[function(require,module,exports) {
//import * as inspector from 'node:inspector';
var parcelHelpers = require("@parcel/transformer-js/src/esmodule-helpers.js");
parcelHelpers.defineInteropFlag(exports);
var _express = require("express"); <-------------------------------------------- error
var _expressDefault = parcelHelpers.interopDefault(_express);
var _cors = require("cors");
var _corsDefault = parcelHelpers.interopDefault(_cors);
var _https = require("https");
var _httpsDefault = parcelHelpers.interopDefault(_https);
var _fs = require("fs");
var _fsDefault = parcelHelpers.interopDefault(_fs);
var _authRoutes = require("./Auth/AuthRoutes");
var _authRoutesDefault = parcelHelpers.interopDefault(_authRoutes);
class Server {
...
bundled from this src:
//import * as inspector from 'node:inspector';
import express, { ErrorRequestHandler } from "express";
import cors from 'cors';
import https from 'https';
import fs from 'fs';
import AuthRoutes from "./Auth/AuthRoutes";
export default class Server {
...
For the release build it throws the following:
ReferenceError: $4qKYl$inspect is not defined
at Object.<anonymous> (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:382384)
at parcelRequire (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:5351)
at Object.<anonymous> (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:375210)
at parcelRequire (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:5351)
at Object.<anonymous> (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:360826)
at parcelRequire (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:5351)
at Object.<anonymous> (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:356488)
at parcelRequire (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:5351)
at Object.<anonymous> (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:356307)
at parcelRequire (file:///mnt/Data/Repos/Demo-Project/build/release/Server/index.js:1:5351)
from this code:
...,parcelRequire.register("4ycop",function(t,r){t.exports=$4qKYl$inspect}),...
and from god knows what source.
Here is the package.json
{
"name": "demo-project",
"type": "module",
"scripts": {
"clean": "rm -rf ./build",
"testServer": "jest",
"testClient": "testcafe",
"build": "parcel build",
"server": "node ./build/dev/Server/index.js",
"servermon": "nodemon --delay 2.5 --watch build ./build/dev/Server/index.js",
"client": "parcel --target clientDev --open --https",
"startcs": "concurrently \"npm run servermon\" \"npm run client\""
},
"targets": {
"serverRelease": {
"context": "node",
"engines": {
"node": ">= 18"
},
"outputFormat": "esmodule",
"scopeHoist": true,
"isLibrary": false,
"optimize": true,
"includeNodeModules": true,
"sourceMap": false,
"source": "./src/Server/Api/index.ts",
"distDir": "./build/release/Server",
"publicUrl": "/"
},
"serverDev": {
"context": "node",
"engines": {
"node": ">= 18"
},
"outputFormat": "esmodule",
"scopeHoist": false,
"isLibrary": false,
"optimize": false,
"includeNodeModules": false,
"sourceMap": true,
"source": "./src/Server/Api/index.ts",
"distDir": "./build/dev/Server",
"publicUrl": "/"
},
"clientRelease": {
"context": "browser",
"engines": {
"browsers": "> 0.5%, last 2 versions, not dead"
},
"outputFormat": "esmodule",
"scopeHoist": true,
"isLibrary": false,
"optimize": true,
"includeNodeModules": true,
"sourceMap": false,
"source": "./src/wwwroot/signIn.htm",
"distDir": "./build/release/Client",
"publicUrl": "/"
},
"clientDev": {
"context": "browser",
"engines": {
"browsers": "> 0.5%, last 2 versions, not dead"
},
"outputFormat": "esmodule",
"scopeHoist": false,
"isLibrary": false,
"optimize": false,
"includeNodeModules": true,
"sourceMap": true,
"source": "./src/wwwroot/signIn.htm",
"distDir": "./build/dev/Client",
"publicUrl": "/"
}
},
"devDependencies": {
"@types/cors": "^2.8.13",
"@types/express": "^4.17.17",
"@types/jest": "^28.1.3",
"@types/react": "^18.0.21",
"@types/react-dom": "^18.0.6",
"buffer": "^6.0.3",
"concurrently": "^7.6.0",
"crypto-browserify": "^3.12.0",
"events": "^3.3.0",
"https-browserify": "^1.0.0",
"jest": "^28.1.3",
"jest-cucumber": "^3.0.1",
"kill-port": "^2.0.1",
"nodemon": "^2.0.22",
"os-browserify": "^0.3.0",
"parcel": "^2.7.0",
"process": "^0.11.10",
"punycode": "^1.4.1",
"querystring-es3": "^0.2.1",
"stream-browserify": "^3.0.0",
"stream-http": "^3.2.0",
"testcafe": "^2.6.2",
"ts-add-js-extension": "^1.4.0",
"ts-jest": "^28.0.7",
"ts-node": "^10.9.1",
"typescript": "^4.9.5",
"url": "^0.11.0",
"util": "^0.12.4"
},
"dependencies": {
"@mysql/xdevapi": "8.0.33",
"axios": "^0.27.2",
"cors": "^2.8.5",
"date-fns": "^2.29.2",
"express": "^4.18.2",
"jose": "^4.9.2",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"secure-random-password": "^0.2.3"
}
}
if i am using Parcel (or something else) incorrectly please let me know. I've followed the Parcel docs and i expect it to work OOTB as it is touted as doing.
Going to try a different bundler instead.
- <script src="../src/index.tsx" type="module"></script>
+ <script type="module">
+ import "../src/index.tsx";
+ </script>
We are giving this a try now - given this can be an intermittent issue we need to keep an eye on it, but the change didn't break anything and our previously failing deployment has worked.
Thanks so much for posting this - I'm hopeful it'll help us get past this problem at least until root cause is sorted.
We are giving this a try now - given this can be an intermittent issue we need to keep an eye on it, but the change didn't break anything and our previously failing deployment has worked.
Sadly this has ended up being an incorrect statement. We've seen that images loaded using import (and require when tested) don't load correctly if you are in a url subfolder (example.com/ would work fine, but example.com/hello/ would not).
This is still a smaller problem than the main one, but definitely something to test if you use the workaround.