Normalize relative external paths. - #591
Conversation
| }); | ||
|
|
||
| this.entry = unixizePath( options.entry ); | ||
| this.entryId = null; |
There was a problem hiding this comment.
You don't need to create this variable. Use this.entryModule.id instead.
There was a problem hiding this comment.
I tried to, but this.entryModule is null at this point. This is because it is still being fetched (and it won't be completed until all its dependencies are fetched too).
There was a problem hiding this comment.
That's too bad. I guess it's fine then.
|
I added another test case, thought of it today: Let's say that for some reason we want both Of course my patch fixes this too. @Victorystick Is there anything still holding us back from merging this? Can I help somehow? |
|
@fatfisz I think it's looking good. /cc @rollup/collaborators |
|
LGTM! Thanks @fatfisz, sorry for the wait – going to merge a few other PRs then cut a new release shortly 👍 |
I've encountered a problem in such a scenario:
rollup)../../module)It turned out that the imported module in the bundle was still
../../module, while I expected it to be normalized with respect to, let's say, the entry file.I investigated a bit and found out something scary: if a relative module is imported from many files in a nested structure, there will be more than one import in the resulting bundle.
For example, I get this:
instead of this:
This PR fixes that problem by normalizing the paths with respect to the resolved entry directory.
I probably did some terrible mistakes because I don't fully understand what's happening there. So please be gentle 😉