Symlinks expand paths of node_modules about webpack-bundle-analyzer HOT 13 OPEN

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?

from webpack-bundle-analyzer.

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?

from webpack-bundle-analyzer.

Sure thing @th0r :)

from webpack-bundle-analyzer.

@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.

from webpack-bundle-analyzer.

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.

from webpack-bundle-analyzer.

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

from webpack-bundle-analyzer.

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.

from webpack-bundle-analyzer.

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

from webpack-bundle-analyzer.

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.

from webpack-bundle-analyzer.

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.

from webpack-bundle-analyzer.

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.

from webpack-bundle-analyzer.

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?

from webpack-bundle-analyzer.

@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.

from webpack-bundle-analyzer.