CommonsChunkPlugin and "Path doesn't exist " error

[andresmatasuarez]

Hi guys, I am trying to unit-test my Angular/Webpack client app with Karma and I am having this issue:

Path doesn't exist '/_karma_webpack_/tests/client/bundle.js'

The full stacktrace is:

Hash: 9b6f94f8eebdbe733525
Version: webpack 1.12.4
Time: 30ms
  Asset     Size  Chunks             Chunk Names
commons  1.25 kB       0  [emitted]  commons
chunk    {0} commons (commons) 0 bytes [rendered]
webpack: bundle is now VALID.
webpack: bundle is now INVALID.
13 11 2015 17:09:21.244:ERROR [karma]: [Error: Path doesn't exist '/_karma_webpack_/tests/client/bundle.js']
Error: Path doesn't exist '/_karma_webpack_/tests/client/bundle.js'
  at MemoryFileSystem.readFileSync (/home/andres/workspace/angular-express-passport-seed/node_modules/karma-webpack/node_modules/webpack-dev-middleware/node_modules/memory-fs/lib/MemoryFileSystem.js:79:10)
  at MemoryFileSystem.readFile (/home/andres/workspace/angular-express-passport-seed/node_modules/karma-webpack/node_modules/webpack-dev-middleware/node_modules/memory-fs/lib/MemoryFileSystem.js:207:21)
  at doRead (/home/andres/workspace/angular-express-passport-seed/node_modules/karma-webpack/index.js:156:26)
  at Plugin.readFile (/home/andres/workspace/angular-express-passport-seed/node_modules/karma-webpack/index.js:160:3)
  at /home/andres/workspace/angular-express-passport-seed/node_modules/karma-webpack/index.js:176:17
  at nextPreprocessor (/home/andres/workspace/angular-express-passport-seed/node_modules/karma/lib/preprocessor.js:73:28)
  at /home/andres/workspace/angular-express-passport-seed/node_modules/karma/lib/preprocessor.js:96:7
  at /home/andres/workspace/angular-express-passport-seed/node_modules/karma/node_modules/graceful-fs/graceful-fs.js:76:16
  at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:380:3)

My webpack.config.js plugins section is as follows:

plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name      : 'commons',
      minChunks : 2
    }),

    new AssetsWebpackPlugin({ path: './bundle' })
]

This issue gets resolved if I remove the CommonsChunksPlugin. I know that the commons plugin is useless for testing (as it don't affect execution), but it is extremely ugly to add a "if process.env.NODE_ENV === 'test'" condition on the webpack config file, besides considering that if it is so useless to the testing process, then I think it should be karma-webpack who makes that choice and disables it transparently to the developer.

What do you guys thinks? Is there any temporal workaround for this that I am not aware of?

[melbarra88]

I had the same problem, and I resolved it this way :

// in my karma.config.js file

var webpackConfig = require('./webpack.config'); // require the project webpack config (it's just node js module, so you can require it)
webpackConfig.plugins = []; // by overriding plugins, we remove CommonsChunkPlugin
webpackConfig.entry = ""; // you can override anything you want from the project webpack config
// Karma config
module.exports = function (config) {
    config.set({
...
        preprocessors: {
            'tests.bundle.js': ['webpack']
        },
        webpack: webpackConfig,
...

By doing this, it is Karma who makes the choices and disable what should be disabled.

[andresmatasuarez]

Great! It is a good workaround nonetheless and I have already included it in my project. However I still feel that this could be a great addition to the module to power development transparency.

And also to save X headache hours of future developers that stumble upon this same issue

[goldhand]

I think having a separate webpack.test.config or a few exceptions for process.env.NODE_ENV === 'test' is a reasonable development expectation.
There are a few plugins (including Commons) that won't work with karma-webpack and are not important for testing but I don't think karma-webpack should be expected to work with all plugins a developer might include in their config.

Maybe adding better error reporting so you can better determine the plugin causing errors or documenting known supported plugins would be the best route.

[goldhand]

I'm going to close this and open an issue to note to add supported plugins to docs.