New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using CommonsChunkPlugin #22

Closed
artur-charcenko opened this Issue Sep 2, 2014 · 13 comments

Comments

Projects
None yet
@artur-charcenko
Copy link

artur-charcenko commented Sep 2, 2014

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

@sokra

This comment has been minimized.

Copy link
Member

sokra commented Sep 2, 2014

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

@mruzekw

This comment has been minimized.

Copy link

mruzekw commented Nov 7, 2014

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?

@mruzekw

This comment has been minimized.

Copy link

mruzekw commented Nov 10, 2014

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

This comment has been minimized.

Copy link

marr commented May 31, 2015

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

This comment has been minimized.

Copy link
Collaborator

goldhand commented Jul 26, 2016

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

This comment has been minimized.

Copy link
Contributor

MikaAK commented Jul 26, 2016

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

@d3viant0ne

This comment has been minimized.

Copy link
Member

d3viant0ne commented Jul 26, 2016

@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

@d3viant0ne

This comment has been minimized.

Copy link
Member

d3viant0ne commented Jul 26, 2016

@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.

@d3viant0ne d3viant0ne added this to the 3.0.0-alpha.0 milestone Jan 16, 2017

@filipesilva filipesilva referenced this issue Apr 21, 2017

Merged

perf(aio): improve unit test rebuild time #16250

1 of 3 tasks complete
@jack-vo

This comment has been minimized.

Copy link

jack-vo commented Jul 8, 2017

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');
  1. 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

This comment has been minimized.

Copy link

deju commented Aug 2, 2017

@jack-vo It is pretty cool!

@nemtsov

This comment has been minimized.

Copy link
Contributor

nemtsov commented Jun 9, 2018

@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

This comment has been minimized.

Copy link

fzxt commented Aug 30, 2018

@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)

@evilebottnawi

This comment has been minimized.

Copy link
Member

evilebottnawi commented Dec 10, 2018

webpack@3 is deprecated so issue not actual

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment