Manual chunks support - #2084

This looks like manualChunks could be an array as well. However when specifying something like manualChunks: ['file.js'] via config file, I get a type error. This should either be fixed (and tested) or removed.

Good catch, will remove this. Yes manual chunks must be named (and it would be string[][] anyway if we did permit an array form).

(Correct the object case to be string[] too!)

chunk should probably be something better describing its content like ids or chunkIds.

With the recent additions, the complex buildChunks has grown a lot more complex with lots of local variables with similar names and unclear scopes floating around. manualChunkModules could be avoided by extracting its generation into e.g. a helper function getManualChunkModules(manualChunks, entryAndManualChunkIds, entryAndChunkModules).

Good suggestion

One important use case I see for this feature is to inline all modules imported by the "first" entry point in a base chunk so that initially, no secondary chunks need to be loaded. To specify this, one would probably write something like

{
  input: ['main1', 'main2'],
  manualChunks:{
    initial: ['main1']
  },
  ...
}

Currently, this will throw a "duplicate entry points" error since analyseExecution will already assign an alias to this chunk which is considered to be the relevant flag for this error. One solution would be to not list main1 in the input list but then the initial chunk can have exports that are not part of the main1 interface as the chunk is considered internal.

Ideally, I would assume we check for duplicate entry points only within input and manualChunks separately but allow a manual chunk to be the same as an input entry point. In case those match up and no additional facade is necessary, I would further expect the resulting chunk to receive its name via input (otherwise, the non-facade chunk should probably get the manual chunk name).

As this will probably make the existing logic even more complex, maybe there is a way to extract more of this chunking logic out of buildChunks into separate helpers.

You've brought up an interesting case, and this is really good to poke holes in the model. The difficulty with supporting this case is there are a few questions in relating it to the aliasing model:

• Should the chunk alias for main1 be called main1 or initial?
• Should the chunk name for main use the chunkNames rule or the entryNames rule? Since it is defined as both a manual chunk and an entry, we don't currently have a way to deal with this.

Note from a chunking point of view (naming aside), this scenario is equivalent to just having:

{
  input: ['main2'],
  manualChunks:{
    initial: ['main1']
  },
  ...
}

One alternative might be to have the manual chunk called initial get created, and then have the input become simply a reexporting facade module pointing to the manual chunk? That might be a way around the naming model issues here.

In fact the above would provide a general solution to the duplicate entry error, allowing us to have a way of always dealing with this case, removing the error entirely.

To summarize the approach taken in the latest commit:

Should the chunk alias for main1 be called main1 or initial?

The manual chunk is created, and then seen to be an entry module facade - therefore it takes the place of main1, and gets called main1. If the chunk had had other modules in it then a new reexporting facade would have been used to the chunk.

Should the chunk name for main use the chunkNames rule or the entryNames rule? Since it is defined as both a manual chunk and an entry, we don't currently have a way to deal with this.

When a chunk corresponds to an entry point facacde as in this case, the manual chunk name does not apply at all, with the entry naming scheme precedence.

This will still require two separate downloads but I guess this is certainly the cleanest approach 👍