This is a placeholder for a JS bundle analysis feature we will explore in Q3/Q4 2018: deep analysis and webperf recommendations based on your Source Maps. Something that iterates on webpack-bundle-analyzer perhaps.

Most developers I speak to are painfully unaware that they probably need to use a bundle analysis tool to discover issues in their JS and modern tools don't seem to be yelling at them loudly enough when they run into problems.

It wouldn't be easy...so..opening to discuss :)

When working with partner teams, we often find the following to be true:

• Folks are usually not using a tool like source-map-explorer or Webpack Bundle Analyzer until they realize they have performance issues with JS bundles. Opportunity for us to inform them of issues before they learn about these tools.
• When folks do discover these tools, it's not trivial to read the dependency graph visualizations and get the "so...what are my next steps here?" guidance out. We could codify some of the patterns we commonly see teams failing on and try to offer up audits around this.
• Potential audits:
  • Library-specific:
    • We noticed you're using all of Lodash in your bundle, but you're only actually calling 3 methods. Maybe use lodash-es or lodash-webpack-plugin to reduce the size of your bundle
    • We noticed you're using Moment.js, but including all of the default locales, bloating your bundle by a few hundred KB. Switch to using specific locales you wish to support to automate this using Webpack's contextual replacement plugin to trim down your bundle.
    • Debug version of React. Switch to production version.
  • Polyfill-specific: We noticed you're shipping a whole lot of Babel polyfills / core-js. Most modern browsers already support features like ES promises so...maybe use babel-preset-env and don't ship all these polyfills in your bundles.
  • Duplicate-entries: We noticed you're including a bunch of duplicate entries (e.g imports, vendor libraries) in your bundle. Maybe you should avoid this. Check out tools like Bundle Buddy and see if they can help.

etc. This could be really neat but does come with some concerns outside of whether it's technically feasible or not:

• How can we keep up with the times when it comes to these toolchain specific recommendations? Do we just bite the bullet and say we'll survey for what is still valid every year?
• Would it make more sense to scope this down to framework specific audits?

Webpack Bundle Analyzer for anyone unfamiliar with it:

cc @brendankenny @paulirish @patrickhulce