Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup adds two upper dirs in the output #4349

Closed
StreetStrider opened this issue Jan 15, 2022 · 6 comments · Fixed by #4419
Closed

Rollup adds two upper dirs in the output #4349

StreetStrider opened this issue Jan 15, 2022 · 6 comments · Fixed by #4419

Comments

@StreetStrider
Copy link

Rollup Version

2.64.0

Operating System (or Browser)

GNU/Linux

Node Version (if applicable)

v14.17.0

Link To Reproduction

https://replit.com/@StreetStrider/rollup-repro

Expected Behaviour

Output is:

foo1 FOO
foo2 FOO

Actual Behaviour

Error is: Error: Cannot find module '../../..'
MODULE_NOT_FOUND

@dnalborczyk
Copy link
Contributor

dnalborczyk commented Jan 17, 2022

there's a couple things not quite right with the repro, although there seems to be a bug nonetheless. depending on what your issue is referring to:

  • the index file is not being found automatically. you have to use the node-resolve plugin in order to make rollup search for files the same way as node.js does (that said: it's not the entire truth either, as rollup currently resolves [some] file extensions automatically, which should also be part of the functionality of the node-resolve plugin.)
  • you can't declare the entry module as external

the actual bug seems to be that the file resolution for going to the parent folder is [not always] working:

import foo2 from '..'  // works
import foo2 from '../'  // does not work, works in node.js
import foo2 from '../.'  // does not work, works in node.js
import foo2 from './..'  // does not work, works in node.js
import foo2 from './../'  // does not work, works in node.js
import foo2 from './../.'  // does not work, works in node.js

not sure [yet] if the issue is with rollup itself, as your repro is not using the node-resolve plugin, or in the plugin, or both.

@StreetStrider
Copy link
Author

StreetStrider commented Jan 17, 2022

@dnalborczyk I see your confusion, I'll try to put more details. My only issue is two upper dirs added. I'm not using node-resolve intentionally, because I don't need it. I need 1-to-1 transformation to CJS only, all modules external, then later Node runtime will resolve according to Node resolve strategy. So I expect it to not transform paths at all. But one specific case (../) works with the flaw. If I use ../index it works properly. (Still, I don't need to resolve index via Rollup, that is not an issue)

Sorry, I put no details initially because I was trying to follow template. My previous ticket #4033 was just ignored. I think that is because it was not following the template (despite the fact the ticket was created before introduction of the template).

I also have ticket in rollup/plugins#959 with node-resolve (similar to how your thought worked), but later I understand that this is not what I needed. node-resolve even conflicts explicitly with all external mode.

The issue is clearly with Rollup core, because my repro not using any plugins (intentionally) and the bug is there.

@dnalborczyk
Copy link
Contributor

I'll have to check how the mechanics work.

My previous ticket #4033 was just ignored.

I don' think anyone purposely ignored your issue 😄 it's just that no one has gotten to it [yet].

@StreetStrider
Copy link
Author

@dnalborczyk you know, sometimes this might happen. When project sets up a specific issue template they often ignore non-formal issues as a measure to keep tracker in order (to motivate people to follow the template). My ticket may got into shadow zone close to the date when form was introduced but not yet and may be ignored as a result of new policy applied to older ticket. (my guess)

@lukastaegert
Copy link
Member

Sometimes there are just a lot of issues and we as we have very few people available, issues that seem very edge case or non-critical can seem to be ignored in favour of more critical ones that affect more users etc. This is not out of spite but out of bandwidth, and if there is no communication for some time, it likely means that this issue needs someone to drive its resolution forward actively.
The most successful strategy is to try to fix an issue yourself. A PR, even a bad one, can go a long way, and can easily be improved in discussion with collaborators. If the mechanics are too complicated, a PR with a failing test can also go a long way as it can easily be picked up by a maintainer, saves us a lot of time and means we can concentrate on the fix.

@lukastaegert
Copy link
Member

Created a fix in #4419

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants