What kind of change does this PR introduce?
feature

Did you add tests for your changes?
yes

If relevant, link to documentation update:
TODO

Summary
This adds a new Plugin which automatically creates commons chunks and vendor chunks with minimal configuration.

By default it creates async commons chunks for everything on-demand loaded. It starts creating commons chunks when they reach a minimum size of 30kb. It ensures that at a split point only issues a maximum of 4 requests and uses the 4 biggest commons chunks that this location. These numbers are open for discussion and configurable. -> optimization.asyncCommonsChunks

When optimization.initialCommonsChunks is truthy it does the same for initial chunks. It's disabled by default because with this switched on you need some infrastructure to generate the HTML from the stats (i. e. HtmlPlugin).

When optimization.initialVendorsChunk: true all node_modules are extracted into a separate initial chunk (named vendors). You can give it a custom name with optimization.initialVendorsChunk: "libs".

When optimization.initialVendorsChunk is an object you can create multiple vendors chunks based on regular expressions or string prefix:

optimization.initialVendorsChunk: {
  react: /node_modules[\\/]react/ // <- adds react, react-dom, react-router, ...
  vendors: /[\\/]node_modules[\\/]/ // <- adds everything else
}

Vendors chunks are only used for an entrypoint when the selected modules are really used. So defining unused vendors doesn't hurt.

The webpack runtime is always kept in the original app chunk, to keep the commons/vendors chunks cachable.

This makes the CommonsChunkPlugin obsolete, it's too complex to use anyway. The commons chunks generated by the new plugin are more efficient and automatic.

Does this PR introduce a breaking change?
yes, because it's enabled by default

Other information