Using CommonsChunkPlugin

[artur-charcenko]

Is there a way to use CommonsChunkPlugin with karma-webpack to exclude vendor libs from test bundles?

[sokra]

nope. We are pretty limited because of the way karma works. This plugin must deliver exactly one output file per input file.

[willmruzek]

I was just about to ask for this as well. There's no way to serve all compiled files to served from webpack to karma?

[willmruzek]

Any chance integration could be achieve by a Karma framework instead of a preprocessor? I'm thinking of something like karma-requirejs: https://github.com/karma-runner/karma-requirejs

[marr]

I'm hitting this issue as well. I'd like to use my separate bundles for running tests with. I created a SO issue here http://stackoverflow.com/questions/30553414/structuring-webpack-config-for-use-with-karma-testing

[goldhand]

I think the best approach is having a separate webpack.karma.config as I mention in #91
I don't think there is any benefit to adding commons plugin support to karma-webpack

[MikaAK]

Agreed with @goldhand, we should document what plugin are _not_ supported with karma-webpack

[joshwiens]

@MikaAK - There is another older issue where someone got the CommonsChunkPlugin to work by tinkering with execution order.

Not saying that we should support it, only that someone got it to work. #24
I'd have to go test this to see if it's a viable though unsupported implementation

[joshwiens]

@goldhand - People are trying to use CommonsChunk to solve performance issues on test runs and after throwing a few hundred tests at karma-wepback to test an old issue, I understand their gripes.

If you think about it, chunking common libs on test runs makes sense from an efficiency standpoint. It's down the road a bit as we have plenty of tech debt to contend with but the ability to do something like this should at least be considered when we start looking at perf.

[jack-vo]

I am using Karma-Webpack for my project and this is how i implement CommonChunkPlugins in Karma-Wepack.

1. I create a dummy file named tests/common.js which i will use as the entry point for my karma's webpack config.
   It can have super simple content like

import 'underscore';
import 'jquery';
import 'backbone';

console.log('Common bundle');

2. Below is my karma.config.js sample, note that when i use CommonChunksPlugin, the options' name is set to tests/common.js as well. Doing it this way will ensure webpack to generate the (virtual) common chunk common.js in the same (virtual) location as the real file (tests/common.js) because karma will not inject your file into the browser if it can not find your file in the system so this is a way to trick karma to inject the generated common chunk file for us. Now you should have all the same vendors like underscore, jquery... moving to that common chunk. You can add more rules to optimise the common chunk further

module.exports = function (config) {
    config.set({
        basePath: '',
        frameworks: ['jasmine', 'requirejs'],
        preprocessors: {
            'tests/common.js': ['webpack', 'sourcemap'],
            'tests/specs/**/*.spec.js': ['webpack', 'sourcemap']
        },
        webpack: {
            context: path.resolve(__dirname, 'tests'),
            entry: {
                common: './common.js'
            },
            devtool: 'inline-source-map',
            output: {
                path: path.resolve(__dirname, 'tests'),
                filename: '[name].bundle.js',
                chunkFilename: '[name].js',
                jsonpFunction: '__TestAmd'
            },
            resolve: {
                alias: {
                    'base': path.resolve(__dirname, 'src')
                }
            },
            module: {
                rules: [
                    {
                        test: /\.js$/,
                        exclude: /(node_modules|bower_components)/,
                        use: [
                            {
                                loader: 'babel-loader',
                                options: {
                                    presets: [
                                        'es2015'
                                    ],
                                    plugins: [
                                        'syntax-dynamic-import'
                                    ]
                                }
                            }
                        ]
                    }
                ]
            },
            plugins: [
                new CommonsChunkPlugin({
                    name: 'tests/common.js',
                    minChunks: function ({ resource }) {
                        return resource &&
                                resource.indexOf('node_modules') >= 0 &&
                                resource.match(/\.js$/);
                    }
                })
            ]
        },

        // list of files / patterns to load in the browser
        files: [
            'tests/test-main.js',
            'tests/common.js',
             {pattern: 'tests/specs/**/*.js', included: false},
        ],

        port: 9876,
        colors: true,
        logLevel: config.LOG_INFO,
        autoWatch: true,
        browsers: ['Chrome'],
        captureTimeout: 60000,
        browserNoActivityTimeout: 100000,
        singleRun: false,
        concurrency: Infinity
    });
};

Hope it helps

[deju]

@jack-vo It is pretty cool!

[nemtsov]

@jack-vo have you had any luck making this work with Webpack 4? It works for me, but I'm getting a "Conflict: Multiple assets emit to the same filename test/common.bundle.js" warning and was wondering if you found a workaround yet. Thanks!

[fzxt]

@jack-vo @nemtsov How did you guys resolve webpackJsonp is not defined errors? Does this work with Webpack 2?

Never mind, for anyone who was unable to get @jack-vo 's workaround, make sure you output the stats of webpack and ensure that there are only 2 bundles being emitted. If there are more than two, it's possible the webpack runtime will be output to another bundle (thats just how it works, if it's not specified in entries)

[alexander-akait]

webpack@3 is deprecated so issue not actual