Improvements on SplitChunks article

[jeremenichelli]

Besides the fact that the document might need some gardening and organization, there are some stuff that I couldn't completely get from the codebase or the config so there are some requests and gaps that might need to be filled.

Specially these:

• include the different things that you can pass to runtimeChunk. It can be a boolean, 'single', 'multiple' or an object that has property name whose value can be either a string or a function of signature (entrypoint: Chunk) => string.
• a paragraph explaining better how enforces works and combines with other options. The enforce allows the special cache group to ignore the minSize, minChunks, maxAsyncRequests and maxInitialRequests set in the overall splitChunks config and purely use test to decide what goes into the chunk. What I'm unclear on is how that fits in when used with reuseExistingChunk.
• cacheGroups can receive a method. What are the arguments and what value needs to be returned.
• function signature description for name option

Article pull request is #1955

[jeremenichelli]

As always, I can help, but need the knowledge 😄

[glen-84]

The magic value true automatically chooses a name based on chunks and cache group key, otherwise a string or function can be passed.

What is the signature for this function?

[jeremenichelli]

@glen-84 that's a missing thing right now. (Added to the issue description)

[thw0rted]

Would this be a good place to request documenting how to pass a function to splitChunks.cacheGroups[xxx].test or should that be its own ticket? The documentation only mentions it in passing, and I haven't been able to reverse-engineer what the callback parameters are on my own at this time.

[thw0rted]

Actually I'm not 100% clear what the regex version of test is testing against, and I'm sure that's complicated by my build chain where I start with Typescript and wind up with name-shorthash.ext. Maybe just a little more detail on test generally? Also: trackback to #2103.

[chrisdothtml]

Fixed by #2183? Or are there still some parts that are unclear?

@glen-84

What is the signature for this function?

relevant section

@thw0rted

Would this be a good place to request documenting how to pass a function to splitChunks.cacheGroups[xxx].test

relevant section

[jeremenichelli]

@chrisdothtml do you feel you've covered what was mentioned in my initial description? If that's the case we can close it for sure.

[chrisdothtml]

• cacheGroups can receive a method. What are the arguments and what value needs to be returned.
• function signature description for name option

I think these ones were covered by my PR

• include the different things that you can pass to runtimeChunk. It can be a boolean, 'single', 'multiple' or an object that has property name whose value can be either a string or a function of signature (entrypoint: Chunk) => string.

Looks like this mostly already exists on the optimization page. Only thing I can see missing is the function signature

• a paragraph explaining better how enforces works and combines with other options. The enforce allows the special cache group to ignore the minSize, minChunks, maxAsyncRequests and maxInitialRequests set in the overall splitChunks config and purely use test to decide what goes into the chunk. What I'm unclear on is how that fits in when used with reuseExistingChunk.

Don't think this exists anywhere currently. Perhaps it could be provided in a tip somewhere on the splitChunks page?

[thw0rted]

Thanks @chrisdothtml , it's a bit more fleshed out, but I'm not sure it's done.

The updated docs say that the function takes one argument, "chunks" (without any description of the type of that argument!). In my testing (webpack 4.8.3) it looks like the callback is actually invoked with two arguments. I logged the prototype of each argument and I see output like NormalModule, [Chunk], where the first argument could also be a DelegatedModule, CssModule, MultiModule, etc.

So, what I'd like to see is:

• double-check the arguments to the callback, I'm guessing the signature is (Module, Chunk[])
• Link to docs about the type of each argument (is the API for NormalModule, Chunk, etc documented somewhere?)
• a slightly expanded example that actually uses some part of the arguments to make a simple decision that would make sense in a real-world project, e.g. I use test: (mod) => mod && mod.resource && mod.resource.endsWith(".special.js") to put .special.js files in their own chunk.

As I said on another issue, my main focus is helping users who either don't have experience with code splitting or didn't fully grok how it worked in the older plugin (like me).

[jonagh]

I think the documentation could still be improved.

1. The documentation (https://webpack.js.org/plugins/split-chunks-plugin/#splitchunks-cachegroups-test) shows a code example defining splitChunks.test (which I dont believe exists?) instead of splitChunks.cacheGroups[yourGroup].test.

2. The example code only illustrates that you can specify a function, it doesn't show any example functionality. It would be beneficial to show use of the test function arguments. It would also be useful to have info about the function parameter types and their properties. Maybe a basic example of what properties one might match against.

3. The example code shows test(chunks) as the function signature yet (from my naive attempts) it seems like the example code in the post by @thw0rted (above) where the signature is test(module) is more correct? Though I am fairly ignorant with regards to the webpack object types - again, type definitions/specs would be useful.

• I'm kind of just repeating thw0rted's post, but thought I'd just re-iterate since this thread (and the docs) haven't been updated (and I just spent too long trying to figure this stuff out).

[aryzing]

Not entirely convinced that this was solved. As @thw0rted mentioned, the knowledge required to effectively configure splitChunks extends beyond knowing function signatures, and into Webpack's OO model for representing modules, dependencies, and other code encapsulation and organization abstractions.

There are several resources online (vid, slides) that try to fill in the gaps, although short of reading the source code, wouldn't it be worthwhile, considering that through the config we can access some of these objects, to add a section in the documentation that covers Webpack's internals?