Feature request: support filtering to parent/sibling chunks via context menu

[bregenspan]

Issue description

(This is a followup to issue #241 which was partially resolved by https://github.com/webpack-contrib/webpack-bundle-analyzer/pull/246)

Now that there is a chunk context menu (as of #246) with support for basic operations such as showing/hiding selected chunks, there's a good foundation for adding the ability to implement the ability to filter to filter to related chunks (e.g. parents/siblings).

This task involves:

• Clearly defining and documenting relationships between chunks: what a Webpack "parent" or "sibling" chunk is (and how the chunk graph differs between Webpack 3 and 4)
• Adding new context menu options to filter to parents and siblings
  • This changeset shows where I reverted changes that add a "filter to parent" option: https://github.com/webpack-contrib/webpack-bundle-analyzer/pull/246/commits/c9bae5b38377bce68613fc03db471a78904e6753. Adding back that particular option might just mean re-applying those changes and then documenting clearly.
• Testing the new options on multiple Webpack project setups (e.g. with various configurations of common chunks/split chunks, dynamic imports)
• Considering how else the UI could be changed to make the new options clear. e.g. when a context menu option is hovered, highlight all of the currently-visible chunks that would be filtered to?

[bregenspan]

(I have a work-in-progress branch for this here: https://github.com/bregenspan/webpack-bundle-analyzer/tree/issue-265-filter-related-chunks, going to find time to test it against various project configurations and finish up documenting the chunk graph)

[bregenspan]

Did some more exploratory work for this in this branch.

But what I'm seeing is that the utility of being able to navigate to parent and sibling chunks varies a lot from project to project, and that in some projects the option might in fact be confusing.

For example:

• A project like https://github.com/webpack/webpack/blob/master/examples/hybrid-routing/router.js is a good use-case. Filtering to the parents of a page-specific bundle that was created using this kind of route-based code splitting (via a dynamic import) allows for quickly visualizing bundles that are needed for a particular page.
• A project using Next.js route-based code splitting (e.g. https://github.com/vercel/next-learn-starter/tree/master/learn-starter) does not have a particularly meaningful parent/sibling relationship between chunks. The loader-based way that the page-specific chunks are created leaves them without defined parents; there is not a very clear graph available that would allow for saying "show me all the other chunks that need to be loaded in order to execute this page-specific chunk".

[armandabric]

A project using Next.js route-based code splitting (e.g. https://github.com/vercel/next-learn-starter/tree/master/learn-starter) does not have a particularly meaningful parent/sibling relationship between chunks. The loader-based way that the page-specific chunks are created leaves them without defined parents; there is not a very clear graph available that would allow for saying "show me all the other chunks that need to be loaded in order to execute this page-specific chunk".

This is really interesting. I'm looking for a way to give meaning to theses Next.js chunks.

At build time Next.js generate a file build-manifest.json that explicit the link between all the chunks (an example https://gist.github.com/Spy-Seth/739eab6d019a568cb1c46f68fe316d89)

I am seeing two way to link theses chunks together:

• Add an option that give explicitly this link
• Add a query string parameter (or a hash one) that allow to pre-filter shown chunk