add splitChunks.maxSize option

[sokra]

add splitChunks.fallbackCacheGroup
add splitChunks.hidePathInfo
move contextify into utils
add some types

fixes #6991
see also #7455 #7456 #4908

This makes AggressiveSplittingPlugin obsolete.

What kind of change does this PR introduce?
feature

Did you add tests for your changes?
yes

Does this PR introduce a breaking change?
no

What needs to be documented once your changes are merged?
for optimization.splitChunks
Using maxSize (either globally optimization.splitChunks.maxSize, per cache group optimization.splitChunks.cacheGroups[x].maxSize or for the fallback cache group optimization.splitChunks.fallbackCacheGroup.maxSize) will try to split chunks bigger than maxSize into smaller parts. Parts will be at least minSize (next to maxSize) in size. The algorithm is deterministic and changes to the modules will only have local impact (so it's usable when using long term caching and doesn't require records). maxSize is only a hint and could be violated when modules are bigger than maxSize or splitting would violate minSize.

maxSize takes higher priority than maxInitialRequest/maxAsyncRequests.

Priority: maxInitialRequest/maxAsyncRequests < maxSize < minSize

When the chunk already have a name, each part will get a new name derived from that name. Depending on the value of optimization.splitChunks.hidePathInfo it will add a key derived from the first module name or a hash of it.

maxSize is intended to be used with HTTP/2 and long term caching. It increase the request count for better caching. It could also be used to decrease the file size for faster rebuilding.

[webpack-bot]

For maintainers only:

• This need to be documented (issue in webpack/webpack.js.org will be filed when merged)

[webpack-bot]

Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.

[webpack-bot]

I've created an issue to document this in webpack/webpack.js.org.