@bregenspan this might be interesting to you, as it seems to overlap a bit with#265

This would be a neat feature. I wonder what would be a nice UI for that? True, showing this information in the tooltip could be a start, but we could probably do more

@TheLarkInn I think it's a duplicate for#41, right?
Showing the whole reasons list in a tooltip won't work because just imagine how huge it will be for e.g. "react" module. There was an attempt to implement it in#85 but I wanted the UI to be more intuitive and convenient. I already have some working code in local branch but unfortunately don't have time now to finish it. But don't worry - it's at the top of must-have features list for the next major version.

Now that there's a context menu concept in place, maybe that could be a good place to trigger this sort of thing. (The current context menu only relates to the bundle, not the specific module selected in the bundle, but this could be changed). Something like opening context menu via right-click/Ctrl-click on a module, clicking "show reasons for inclusion", and this opening a new UI panel with thereasons. That's a click or two more than the approach in#85 though.

@bregenspan yes, that was one of the use cases for the context menu I was talking about in your PR ;)

@th0r@bregenspan:

So I also discussed this with@sokra and it turns out that the data point that should be used isreasons (which lives on the module object). It is not as convienent to work with (vs.module.issuePath) but he described to me an edge-case that would casemodule.issuePath to be inaccurate.

sokra [11:40]
yep, there is an edge case where issuer is not the reason why a module is included in the bundle. A -> B, B -> C, D -> B, B reexports an export of C. B has sideEffects: false, A imports the reexported export from C, D imports something else from B, A is built before D. Here the issuer of B would be A, but the reason why it is included is D.

After learning this, I definitely agree thatreasons is the way to go.

Now that there's a context menu concept in place, maybe that could be a good place to trigger this sort of thing. (The current context menu only relates to the bundle, not the specific module selected in the bundle, but this could be changed). Something like opening context menu via right-click/Ctrl-click on a module, clicking "show reasons for inclusion", and this opening a new UI panel with the reasons. That's a click or two more than the approach in#85 though.

@bregenspan What if you take the same approach that we use in webpack/webpack: In our default stats output, we show all the modules used in a bundle output (as seen below):

We display the top 4 modules index in the chain and then we hide the rest (I think we cap at like 10).

What if we take this same approach:

1. User highlights a module in the default view
2. Reasons displays at bottom of dialogue and truncate, if the user wants to dive in, we open a new view which has a more detailed (full chain analysis) ofwhy that module is in that graph.

@TheLarkInn that sounds good to me! For the semi-related issue#265 (but to do with displayingchunk graph, as opposed tomodule graph details) , I started down this path of showing a simple list of parent chunk names in the tooltip:bregenspan@ea912c7. I could see it making sense to use similar UI both for displaying module graph details (when hovering a module) and chunk graph details (when hovering a chunk) - some small preview in the tooltip followed by context menu interaction to get more details. Maybe with potential to add some hotkeys later on to obviate need for opening context menu at all.

One other avenue for this that could make sense (and would limit the number of UI changes needed) is to add integration withhttps://github.com/webpack/analyse since it already offers the richer context that a number of feature requests are asking for.

I'm imagining something like:

• WhengenerateStatsFile istrue and some newenableWebpackAnalyseTool option istrue:
  • Context menu shows "Analyse" when right clicking a bundle or module
  • "Analyse" open a deep link in to the Analyse tool in a new window, filtered to the appropriate bundle or module by passing the correct GET params/path.

Currently the Analyse tool requires selecting the stats.json file for analysis via UI. To allow for the integration described above, the Analyse tool would need to be updated to add an interface that allows for programmatically accepting stats.json output instead (whether that happens at build time or runtime).

@th0r@valscion
It quite old issue, but surely very needed, do you think you will manage to do that sometime soon ?
I saw there is already PR ready that@th0r created 2 years ago, what's the PR status ? maybe I could help finish it up ?

@netanel89 sorry, but I'm very busy right now so I'm afraid I can't provide even an approximate date when I'll be able to finish this PR 😞

it would be super dope to have this feature. Trying to optimize build for seo and it's taking hours to go through dependencies one by one in reverse order to try to figure out why a specific class ended up in the bundle.

Or maybe someone knows of a good approach/plugin for that?