RFC: a simplified version of the DllPlugin

I was amazed to discover how significant is the impact the DllPlugin has on build performance, especially when projects get bigger.

Here are some numbers I measured on my machine, for a project with a decent amount of dependencies:

	Without DllPlugin	With DllPlugin
Build Time	16461ms - 17310ms	2991ms - 3505ms
DevServer Rebuild	2924ms - 2997ms	316ms - 369ms

Current drawbacks of the DllPlugin

While The DllPlugin is great, its main drawback is the amount of boilerplate it adds to the project.

• separate configuration You have to manage the DLL config separate from the main config and build it in advance.
• Invalidation You have to write your own logic for invalidation or build it by hand. Otherwise, things can get out of sync.

Suggested Solution

Two months ago, while working on a PR to add DLL support for create-react-app, I realized that it is possible to overcome these drawbacks by introducing a high-level version of the plugin that will handle all of the boilerplate by itself.

Which led me to write autodll-webpack-plugin.

This is how it works:

• You add it to your config as a regular plugin (no external config required):

module.exports = {
  entry: {
    app: './src/index.js'
  },

  output: {
    filename: '[name].bundle.js',
    path: path.resolve(__dirname, 'dist')
    publicPath: '/'
  },

  plugins: [
    new AutoDllPlugin({
      filename: '[name].dll.js',
      entry: {
        vendor: [
          'react',
          'react-dom',
          'moment'
        ]
      }
    })
  ]
};

• When you run webpack, the plugin creates the DLL config in memory and builds it before it builds yours. It still uses DllPlugin and DllReferencePlugin under the hood.
• It stores the DLL files in a cache directory, and saves it in a memory-fs too, for faster access when using the dev server.
• On every run, the plugin checks if the cache is still valid, otherwise it will trigger a rebuild.
• There are two conditions for cache invalidation:
  • The options passed to the plugin changed
  • package.json changed (by npm / yarn, or by hand)

Challenges

I got to the point that users request features, such as support for plugins, loaders, inheriting from the parent config, and I encounter problems that are far beyond my understanding of webpack. I worry that I can no longer maintain it alone.

Request

I believe this plugin has potential and people seems to like it.

I hope that maybe one of your team members can take over the project and develop an official version of it, one that will address its current limitations and better fit with webpack’s standards.

With gratitude, Asaf.

[Nargonath]

I’m currently working with @asfktz on this: https://github.com/asfktz/autodll-webpack-plugin/issues/54. I’d be happy to help with whatever works is required to improve the current DLLPlugin implementation. I may not have the best and deepest webpack knowledge but I’m willing to learn and to help.

[alexander-akait]

Yes, agree, let’s close, solution - Module Federation