Repository navigation
Symlinks expand paths of node_modules #64
Description
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?
Activity
th0r commentedon Apr 21, 2017
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 commentedon Apr 21, 2017
Sure thing @th0r :)
dzearing commentedon Apr 21, 2017
@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 commentedon Apr 24, 2017
@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 commentedon Apr 28, 2017
@dzearing So what do you think about filling an issue in webpack repo?
dzearing commentedon Apr 28, 2017
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 commentedon Oct 21, 2017
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_modulesis in the path and eliminate anything before it?valscion commentedon Oct 23, 2017
If anyone could create a simple reproduction repository showcasing this issue, we would be in a better position to triage this :)
markwoon commentedon Oct 23, 2017
You can't commit a symlink into git...
On Windows, you can reproduce it like this:
mklink /J newdir repo)newdirAnd you should see the problem.
valscion commentedon Oct 24, 2017
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 commentedon Oct 25, 2017
Oops, you're right.
If I understand @dzearing correctly, you can reproduce on *nix by moving
node_modulesout of your repo and symlinking to it.dzearing commentedon Apr 28, 2018
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 commentedon Mar 2, 2021
@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.