Webpack - How to create independent entry point (ignore cacheGroups settings)?

user_8965581 0
Viewed 1649

In my webpack config I created 2 cache groups, "vendors" and "common". 

        entry: {
            'entry1': './src/entry1.js',
            'entry2_independent': './src/entry2_independent.js',
        },
        optimization: {
            splitChunks: {
                cacheGroups: {
                    vendors: {
                        minChunks: 30,
                        test: /[\\/]node_modules[\\/]/,
                        name: 'vendors',
                        priority: -10,
                        chunks: 'initial'
                    },
                    default: {
                        minChunks: 30,
                        priority: -20,
                        chunks: 'initial',
                        reuseExistingChunk: true,
                        name: 'common'
                    }
                }
            }
        },

I want one of my entry points to be independent. It should include all its dependencies without being depndent on common.js or vendors.js.

To be more specific, I want all entry points with '_independent' in their name, to be independent.

I still want to preserve the optimization logic. If a module is used in 30 chunks, I still want it to be part of the 'common' layer.

How can I do it?

Thanks!

bundling-and-minification webpack-5 webpack-4 webpack
3 Answers

Return true in name function for all the files that you want to be in that specific cache group

Function name will run on all files that their path match all_files_that_match_this_regex_will_run_name_func.

If the function will return true, this file will be embedded in common chunk.

 common: {
   test: /<all_files_that_match_this_regex_will_run_name_func>/,
   name(fileName) {
      const filePath = fileName.context;
      const regexForFilesInCommonChunks = /isShouldBeInCommon/

      if (regexForFilesInCommonChunks.test(filePath)) {
          return 'common'
      }

      return false;
   }
}
user_34701480

I ended up exporting 2 configs. One which has common layer (common/vendors) and another which creates independent/standalone bundles:

module.exports = function (env) {

    const baseConfig = {
        mode: env.development ? 'development' : 'production',
        devtool: 'source-map',
        watch: !!env.development,
        output: {
            path: path.resolve(__dirname, CONSTS.DIST),
            filename: '[name].js',
            chunkFilename: '[name].js',
            publicPath: '/dist/scripts/',
            globalObject: 'this',
        }
    };

    const clientConfig = Object.assign({}, baseConfig, {
        entry: {
            'client-entry1': './src/entry1.js',
            'client-entry2': './src/entry2.js',
        },
        optimization: {
            splitChunks: {
                cacheGroups: {
                    vendors: {
                        minChunks: 30,
                        test: /[\\/]node_modules[\\/]/,
                        name: 'vendors',
                        priority: -10,
                        chunks: 'initial'
                    },
                    default: {
                        minChunks: 30,
                        priority: -20,
                        chunks: 'initial',
                        reuseExistingChunk: true,
                        name: 'common'
                    }
                }
            }
        }
    });

    const serverConfig = Object.assign({}, baseConfig, {
        entry: {
            'independent-bundle1': './src/entry1_independent.js',
            'independent-bundle2': './src/entry2_independent.js',
        }
    });

    return [clientConfig, serverConfig];
};

If somebody have a better solution which doesn't require 2 different configs, please share :)

user_89655810

I want one of my entry points to be independent. [...]

Notice that all entry points are mutual-independent by default. The most common mistake a naive user might make is module-duplication among entries. Instead, you can use dependOn for one entry to reuse all modules from another one. I think this is another approach than yours, which is also a good practice in my opinion: no-use means not-related.

user_52905190
Related