Symlinks expand paths of node_modules

[dzearing]

Issue description

When this is used in an environment where node_modules packages are symlinked (via lerna, @microsoft/rush, npm link) the locations to npm modules are expanded such that it makes things hard to parse. Basically half of the tree map is dedicated to resolving the node_modules folder:

Would there be any way to fix this such that I can provide "filters" that would alias a folder to say blank string, to remove the extraneous path? Any suggestions, other than to avoid symlinking?

[th0r]

Bad news: seems like webpack doesn't provide a symlinked path in stats info - it only contains already expanded path to the real file.

I think the most proper way to solve it would be filling an issue in webpack repo to include symlinked paths in stats info.

@dzearing Could you do it?

[dzearing]

Sure thing @th0r :)

[dzearing]

@th0r Actually, lets say that webpack is doing the right thing. Technically the path is correct, so I can see them won't fixing that. But it creates a mess in the treemap.

Another alternative would be to collapse folder with only one child into one "box". So in the screenshot above, instead of 6 boxes representing individual folders, you could collapse them into a single "Users/david/fabric/branch3/common/node_modules" entry. This might be a little better, and for long paths, if you had some collapsing logic, like truncating from the middle ("users/.../node_modules") that would be pretty reasonable too.

I don't know how possible this is but thought I'd propose it.

[th0r]

Actually, lets say that webpack is doing the right thing. Technically the path is correct, so I can see them won't fixing that.

@dzearing I'm not saying that webpack does something wrong - it just expands symlinks to the real paths.
Because of this it's not possible to get the original "symlinked path".

What I suggest is to submit a feature request in webpack's repo for them to add another field with symlinked (not expanded) path to stats info that this plugins uses to construct modules treemap.
It won't change any logic in webpack itself, it'll just provide us the data we need.

[th0r]

@dzearing So what do you think about filling an issue in webpack repo?

[dzearing]

Hey @th0r just to be really clear; in the stats file, right now I see fully qualified paths for everything. That includes "module" entries, "moduleName", "moduleIdentifier", etc.

What would you expect here; another entry called "moduleIncludePath" or something, which would be relative to the webpack location without the fully qualified path resolve?

I am not quite sure how to word it so that it can be used here. Just want to make sure I'm not asking for the right thing. I f you know exactly what is needed, feel free to log the issue.

[markwoon]

I'm experiencing this as well.

Any chance we could handle this on the analyzer side? Perhaps a callback for us to normalize paths? Or an option to automatically see if node_modules is in the path and eliminate anything before it?

[valscion]

If anyone could create a simple reproduction repository showcasing this issue, we would be in a better position to triage this :)

[markwoon]

You can't commit a symlink into git...

On Windows, you can reproduce it like this:

1. Checkout a repo
2. cd somewhere else
3. create a symlink to the repo (e.g. mklink /J newdir repo)
4. cd newdir

And you should see the problem.

[valscion]

You can't commit a symlink into git...

Huh? I've done that many times, at least on *nix systems you can commit symlinks.

I don't have a windows machine to create a reproduction case.

[markwoon]

Oops, you're right.

If I understand @dzearing correctly, you can reproduce on *nix by moving node_modules out of your repo and symlinking to it.

[dzearing]

I lost track of this issue, but it is still an issue.

@TheLarkInn This issue makes the treemaps kind of a mess to read for mono-repo scenarios where things get linked up. Do you have suggestions on this one?

[noahnu]

@markwoon's suggestion for a normalize path callback would be great. This is what it looks like for me at the moment, the names are not useful. With yarn 2 (pnp):

I also have absolute paths in some cases due to the yarn global cache.