Other ways to split chunks for federated modules for application code?

[matthewbae]

As of today, I know of two ways to split federated chunks:

1. Using shared settings (only for packages/libraries)
2. Using a dynamic import with next/dynamic

Is there any other way to split federated chunks for application code? I noticed that splitChunks is explicitly deleted on the childCompiler, so that isn't an option. I also don't know of a way to leverage shared settings for application code and not packages/libraries.

[ScriptedAlchemy]

chunk splitting is tricky in federation becuase it messes with the plugins own use of chunk splitting. So i generally turn it off to prevent users from breaking their own builds.

It is possible to enable it, but we would need any custom split rules to use enforce: true in order to override federation chunk split rules.

theres a git issue about chunk splitting on federation examples repo.

Im happy to enable it again if you have a PR that doesnt break functionality of the MFP. usually id delete nexts chunk splitting defaults so i could just remove the default keys and pass any user configured rules through

[matthewbae]

Thanks for the response. I was able to find the git issue you mentioned in the federation examples repo.

After altering the Next.js MF plugin to accept values from splitChunks and removing the next defaults, I was able to get a chunk split. However, my split chunk is not being used by my federated chunks.

This is the optimization.splitChunks object I'm passing to the childCompiler in the Next.js MF plugin:

{
  cacheGroups: {
    testGroup1: {
      test: [Function: test],
      chunks: 'all',
      reuseExistingChunk: false,
      enforce: true
    }
  },
  defaultSizeTypes: [ 'javascript', 'unknown', 'css/mini-extract' ],
  hidePathInfo: true,
  chunks: 'async',
  usedExports: true,
  minChunks: 1,
  minSize: 0,
  minRemainingSize: undefined,
  enforceSizeThreshold: 0,
  maxAsyncRequests: 30,
  maxInitialRequests: 30,
  automaticNameDelimiter: '-'
}

I also changed other fields like minSize since my test component is too small. Is there something obviously missing from the configuration above for optimization.splitChunks? I can create a shareable reproduction if the information above isn't enough.

When you say PR, I'm assuming you are talking about a PR that reintroduces the ability to pass splitChunks while handling next defaults and making sure MFP doesn't break? Is it possible to see the git history for this? I wasn't able to find an old repo with the git history before the NX move.

[matthewbae]

Hi @ScriptedAlchemy just wanted to know if you could provide some feedback to the above or point me to the right folks.

[ScriptedAlchemy]

You have to use SplitChunksPlugin - child compiler dont do much on their own, is the child compiler actually splitting chunks? just not respecting the splits? or completely ignoring?

[matthewbae]

The SplitChunksPlugin options I shared above are what I set in the main webpack configuration. In addition to that, I removed this line and removed the Next.js default code splitting configurations.

The child compiler is not splitting anything at all. It completely ignores what I passed in. The main compiler respects the configuration I passed in for SplitChunksPlugin.

A repro might be helpful, so please let me know if a minimum viable repro is useful here.

[ScriptedAlchemy]

new SplitChunksPlugin(options).apply(childCompiler)

Child compilers are bare.

[matthewbae]

Sorry for the delay @ScriptedAlchemy. I did a test by applying the SplitChunksPlugin to the childCompiler, and the chunk splitting works for me.

I'm happy to submit a PR to allow us to pass in options for SplitChunksPlugin. I see two approaches:

1. Users define their options normally, and the Next.js MF plugin carefully remove the Next.js default options before applying SplitChunksPlugin.
2. Have users define their splitchunks options somewhere else within the options for the Next.js MF plugin and apply them with SplitChunksPlugin.

Based on the history of this thread, it seems like we prefer option #1.

Most likely want to include documentation on this as well.

[github-actions]

Stale issue message