Add "Import Chain" into hoverstate for module.

[TheLarkInn]

Feature description

Currently there is no way to see "why did this module end up in my bundle". It is one of the next actionable items for a developer to solve when they are triaging their JavaScript bundles.

Today, the webpack stats object does provide this information through an API attached to the module called issuerPath. module.issuerPath will provide an array of modules that caused the current module to be imported or added to the bundle.

For example if module c was imported by b and b was imported by a: The issuerPath for module c will be [{id: a}, {id: b}] (always starting with the entry).

I believe that we should display this information when a developer hover's over the module in question they are curious about.

I spent some time last Friday to explore the ./client app which would drive the UI in the analyzer and it looks like the data is "massaged" in a way that extra data noise is removed from the "moduletree data".

Work involved would be: add issuerPath as a property on Module on the anaylseStats fn/side of the app, and then include markup in the ModuleTree to incorporate this feature.
...

[valscion]

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

[valscion]

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

[th0r]

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

[bregenspan]

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.

[th0r]

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

[TheLarkInn]

@th0r @bregenspan:

So I also discussed this with @sokra and it turns out that the data point that should be used is reasons (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 case module.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 that reasons 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) of why that module is in that graph.

[bregenspan]

@TheLarkInn that sounds good to me! For the semi-related issue #265 (but to do with displaying chunk graph, as opposed to module 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.

[bregenspan]

One other avenue for this that could make sense (and would limit the number of UI changes needed) is to add integration with https://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:

• When generateStatsFile is true and some new enableWebpackAnalyseTool option is true:
  • 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).

[netanel89]

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

[th0r]

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