Plugins: Bundle fails for form require('../#/folder') due to hashbang-only directory

[ctjlewis]

• 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 (use yarn test for 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.

[UnbearableBear]

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:

var contains = require("es5-ext/string/#/contains");

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#/contains

Maybe 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]

@UnbearableBear I found this during a stress test, so it's interesting that this actually impacted real-life code; es5-ext is 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]

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]

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.

[SCWR]

I have the same problem when I use css related plugins,

rollup-plugin-css-porter
rollup-plugin-embed-css

[stale[bot]]

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]

Wasn't this addressed in a recent release?