Feedback on the webpack 5 stats output

In this issue I want to collect feedback on the state output for webpack. For webpack 5 we have the change the improve the default output. For webpack 5 the Stats internally has been refactored to extensibility, but the output has kept as it was in webpack 4 (expect for some minor changes).

Please leave any feedback you like. Here are some question to inspire you:

• What information is important for you?
  • Regarding the default output: What pieces of the output did you enable with the stats option?
• What information distracts you and is unneeded?
  • Regarding the default output: What pieces of the output did you disable with the stats option?
• How can information shown in a better way?
  • Readablility?
  • More useful format?
  • Missing aspects?
  • Color and highlighting?
• Maybe paste a screenshot of your output
• Do you use a custom tool for displaying webpack results?

---

Here are some examples of stats output:

Small build:

Small build with many node_modules:

Large build:

Incremental build in watch mode:

---

Here is my own feedback:

• node_modules in the stats is not as useful.
• The assets table doesn’t scale well for many assets or long asset names
• Hash seem to be useless
• Version, Time and Build at could be displayed in a more condensed way, in a single line, headers can be omitted
• There is no success/failure summary. Best this would be at the end of the output.
• Sizes of modules are not as useful as it doesn’t include sizes of dependencies.
• KiB vs MiB is not really obvious, large assets are easy to miss
• hidden modules/assets may confuse
• In small builds:
  • [emitted] is useless
  • Entrypoint is useless when there is only one with a single file
  • Asset meta info like [name: main] is useless
  • Time is useless
  • Module meta info like [built] and size is useless
• In large builds:
  • Long list of files for an Entrypoint is useless
  • List of 15 (random?) modules is useless in first build, but useful in incremental build
  • Assets list is useless in first build, but useful in incremental build
  • All [dev] assets are useless

Here are some ideas:

• Hide [dev] assets by default
• When assets > 15, group them by extension and flags:
  • 14 *.js [emitted] [immutable], 4 *.js [emitted], 13 *.css [emitted] [immutable]
  • always show assets which are too large
• Hide Entrypoints by default when 1 entrypoint with 1 file
• Show total size of files in entrypoint
• Summarize entrypoint files when > 5: Entrypoint main = 7 asset 3.45 MiB (14 auxilary assets 3.45 MiB)
• Hide module size by default
• Hide [built] flag when only build assets are shown
• Hide [emitted] flag when only emitted assets are shown
• Show summary of hidden asset/modules
  • + 9 hidden asset (3 not emitted assets, 6 dev assets)
  • `+ 541 hidden modules (500 not built modules, 32 not included modules, 9 runtime modules)
• Display assets in list instead of table, like modules
• remove color from folders in asset name, highlight the extension.
• Instead of hiding modules that doesn’t fit in the limit, group them by folders
  • This should automatically group node_modules in a useful way
• Show modules in a tree groups by folder
  • show only folder summary when module limit has been reached
  • excluded modules will always by show as summary
  • Can we do the same for the assets list?
  • Should this be done in the JSON too?

./js/
  index.js 7.85 KiB [built]
  indexedDB.js 1.04 KiB [built]
  butterchurnOptions.ts 2.92 KiB [built]
  dropboxFilePicker.ts 923 bytes [built]
../node_modules/
  raven-js/ 5 modules 838 bytes [built]
  react/ 4 modules 190 bytes [built]
  react-dom/ 6 modules 1.33 KiB [built]
  raven-for-redux/built/ 10 modules 2.22 KiB [built]
  butterchurn/lib/isSupported.min.js 1.4 KiB [built]
../skins/base-2.91-png.wsz 104 bytes [built]
../js/
  constants.ts 1.33 KiB [built]
  selectors.ts 18.4 KiB [built]
  actionTypes.ts 4.48 KiB [built]
  webampLazy.tsx 9.58 KiB [built]
  actionCreators/index.ts 4.15 KiB [built]

[alexander-akait]

@erykpiast ?

const { modules } = stats.toJson({ source: true });

[wojtekmaj]

Yes, I’m talking about this…

For comparison, this is how it used to work before. Sure, not ideal, but better in my opinion: