Repository navigation
Bundle fails for form require('../#/folder') due to hashbang-only directory #528
Description
- Rollup Plugin Name:
commonjs - Rollup Plugin Version: 14.0.0
- Rollup Version: 1.27.14
- Operating System (or Browser): Ubuntu
- Node Version: v12.18.2
- Link to reproduction (
⚠️ read below):
https://repl.it/@christiantjl/rollup-hashbang-dir (useyarn testfor repro)
Expected Behavior
Bundle produced at output/bundle.mjs.
Actual Behavior
Error is thrown, presumably due to hashbang-only directory in filepath and/or index.js assumption (see below).
Additional Information
I'm working to stress test Rollup against the entire dependency tree of the top 100 or so npm packages, which involves loading a set of plugins for legacy compatibility: commonjs, node-resolve, and json. That work will be ongoing in a separate repo, but I wanted to submit this bug report in advance since it was the most common error at compile-time (the stress test will also run the bundle through node runtime).
import statements for vast majority of these 1300 or so packages will indeed bundle, but a few (~17) do not, ~75% of which are modules that rely on a popular package called es5-ext. Some packages which cannot bundle because of this error include: d gulp es6-iterator es6-symbol es6-weak-map gulp gulp-cli last-run semver-greatest-satisfied-range sver-compat undertaker
Consider the example module on repl.it, that just imports this package to demonstrate:
import hashbangDirInDepTree from 'es5-ext';Bundling with the plugins I mentioned throws:
index.mjs → output/bundle.mjs...
[!] (plugin Rollup Core) Error: Could not load /home/runner/rollup-hashbang-dir/node_modules/es5-ext/array/index.js#/compact (imported by /home/runner/rollup-hashbang-dir/node_modules/es5-ext/json/safe-stringify.js): ENOENT: no such file or directory, open '/home/runner/rollup-hashbang-dir/node_modules/es5-ext/array/index.js#/compact'
Notice how it attempts to resolve to array/index.js#/compact and not array/#/compact/index.js for what I assume is https://github.com/medikoo/es5-ext/blob/master/json/safe-stringify.js#L3 :
var compact = require("../array/#/compact")Please let me know if I have been unclear or can otherwise provide more information. The error message indicates Rollup Core, but I believe it's the CommonJS plugin that is directing Core to load a nonexistent file so I opened the issue in this repo.
Activity
[-]CommonJS plugin fails for form require('../#/folder') due to hashbang-only directory[/-][+][commonjs] Bundle fails for form require('../#/folder') due to hashbang-only directory[/+]UnbearableBear commentedon Aug 5, 2020
I might be wrong but it seems that this issue is prior to v14.0.0
We have the exact same issue in our repo, I confirm that things such as:
like here (https://github.com/medikoo/d/blob/master/index.js#L7)
are, I assume, wrongly converted to this path:
es5-ext/string/index.js#/containsMaybe we should be able to provide an option to allow this kind of char in the require path to be considered as part of the actual path ?
ctjlewis commentedon Aug 5, 2020
@UnbearableBear I found this during a stress test, so it's interesting that this actually impacted real-life code;
es5-extis a super common dependency, so it's not that surprising I guess.I will try to work on a fix soon. Smarter people than me like @Andarist or @lukastaegert might have some advice on where to start regarding this issue.
UnbearableBear commentedon Aug 5, 2020
Thanks a lot ! I'll try to cast an eye over it too but I'm going on holidays tomorrow so that's going to be shhhort
Andarist commentedon Aug 6, 2020
Well, I'm not aware of any special use cases for
#in the path - are there maybe some tests for this? If we could establish that there are no special use cases for#then I would stay that the resolving logic should be tweaked to just consider#a part of the actual fs path.[-][commonjs] Bundle fails for form require('../#/folder') due to hashbang-only directory[/-][+]Bundle fails for form require('../#/folder') due to hashbang-only directory[/+]SCWR commentedon Sep 10, 2020
I have the same problem when I use css related plugins,
rollup-plugin-css-porter
rollup-plugin-embed-css
stale commentedon Nov 10, 2020
Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it. ⓘ
ctjlewis commentedon Nov 10, 2020
Wasn't this addressed in a recent release?
Emptymu commentedon Jul 7, 2021
For anyone having this problem, update your
@rollup/plugin-node-resolve.Here is the MR that fixed it:
#588