RFC: Webpack Diagnostics Meta Data #17067

Feature request

What is the expected behavior?
Hope that webpack can provide a built-in data structure for analysis and diagnosis of the bundle process and product.

What is motivation or use case for adding/changing the behavior?
The existing stats data is not conducive to bundle analysis and diagnosis. In order to deeply analyze the entire webpack bundle process, developers often need to do some extra work to reassemble a data structure, such as

• Data Collection: Register various hooks to obtain sufficient information
  • Intercept loader to collect the loader data, for querying the loader that the file has passed through, as well as the time and intermediate products of each loader
  • Intercept compiler/compilation hooks to collect the plugin data, for recording the running order and running time of external plugins in hooks
  • Reassembling resolver data, for tracking the process status of compiling all paths within the project, aiming to help users identify how the erroneous path is generated
  • Stringify the webpack configuration, allow users to easily view the currently effective configuration
• Data Processing: In the process of collecting data, create data structures for analysis and diagnosis
  • Generate chunk graph
  • Generate module graph
  • Generate package graph
• Data Diagnosis: Users often need to manually troubleshoot issues, so we could establish a set of Linter mechanisms, and write rules to take processed data as input and output diagnostic results, used to diagnose such things as
  • Writing rules to take processed data as input and output diagnostic results, used to diagnose such things as
    • Duplicate Packages
    • Default Import Check
    • Loader Performance Optimization
• Data Display: Write web pages to display processed data in a user-friendly interface and assist users in troubleshooting problems through visual aids, even directly locating problematic code and fixing it with one click

How should this be implemented in your opinion?

1. Design a standardized diagnostic data structure and linter mechanism that allows developers to investigate the bundle process and develop rules around this data structure. To avoid affecting the build time of the production environment, it is necessary to use a configuration to enable it.
2. Develop a webpack plugin that reads this meta data through a diagnostic service and provides users with web pages and api for troubleshooting and diagnosis:

• Compile Analysis

  1. Webpack Loaders: Investigate and analyze Webpack Loaders-related call data and time-consuming information
  2. Webpack Plugins: Query the number of calls and time of Webpack Compiler / Compilation Hooks
  3. Module Resolve: Help you quickly query the final path after the module path of an import/require in a file is parsed

• Bundle Analysis

  1. Bundle Size: The volume data, first screen resource size, duplicate package, module reference relationship and other information of the current compiled product
  2. Tree Shaking: Help you further analyze and investigate the tree shaking bailout reason of a file in the project

• Prototype Page

  • Overall Page: In addition to giving an overall overview, we will also provide a Bundle Alerts module to scan for problems to be fixed through rules, such as duplicate package detection. It supports the tracing of each duplicate package introduction chain.
    

  • Loader Page: Show the loader timing diagram, as well as the loader time consumption and changes before and after the loader of each module.It not only supports viewing the Loaders details of a single file, but also supports viewing the Loaders data of the file directory.
    
    

  • Plugin Page: Support viewing the call data information of all plugin-in-used Compiler Hooks and Compilation Hooks in the current Webpack project
    

  • Bundle Page: Show the parsed size of each module, that is, the volume actually packaged into the bundle product.
    
    

  • Tree shaking Page: You can know the reason why the code is not shaken for reasons such as "where variables are used" through it.
    

Consider this too - #20435

Are you willing to work on this yourself?
yes

@TheLarkInn