bail option does not exit the process

[timaschew]

If I use the bail option I get this error

Hash: 8344a6c0a9b3c44a5636
Version: webpack 1.10.3
Time: 27501ms

ERROR in ./lib/forgot-password/client/view.coffee
Module not found: Error: Cannot resolve module 'component-eemitter' in /home/vagrant/lib/forgot-password/client
 @ ./lib/forgot-password/client/view.coffee 7:10-39
Hash: 8344a6c0a9b3c44a5636
Version: webpack 1.10.3
Time: 477ms

ERROR in ./lib/forgot-password/client/view.coffee
Module not found: Error: Cannot resolve module 'component-eemitter' in /home/vagrant/lib/forgot-password/client
 @ ./lib/forgot-password/client/view.coffee 7:10-39

and then nothing happens, but the process is still alive. After 5 minutes I stopped it.

If I run webpack only with --bail it works fine.

maybe related to #49

[cskeppstedt]

I'm having the same problem. We're not running the webpack CLI, but using it programmatically in our builds. config.bail = true works when running the build, but when we run the same config inside karma-webpack, the process won't exit (just hangs).

"karma-webpack": "1.7.0"
"webpack": "1.12.2"

[goldhand]

As mentioned in #49, these two plugins might help solving this issue:

https://gist.github.com/Stuk/6b574049435df532e905
https://gist.github.com/mvgijssel/d3b121ad50e34c09a124

[joshwiens]

Workarounds aside, we should be respecting the bail option inside the loader no?

[goldhand]

@d3viant0ne Most certainly! I kind of just pinned those plugins for reference thinking they might be useful while investigating a fix. I'd say this is a pretty high priority fix. I'd hate to have something deploy even though tests fail.

[pablorsk]

Hi!

I have a same problem but with tslint-loader, dont exit if preloader emmit erros. I'm using this like ts-lint-loader documentation

  tslint: {
      configuration: require('../tslint.json'),
      emitErrors: true,
      failOnHint: true
  }

I receive messages like "Module build failed: Error: Compilation failed due to tslint errors." but karma-webpack keep running.

[abstiles]

I wrote and published a plugin on NPM that solves this problem for my own needs. It propagates warnings and errors up to the console and ends the process with a non-zero exit code if it encounters an error. If anyone else is interested in it, it's webpack-karma-die-hard.

[rcchen]

For what it's worth bail: true appears to be working correctly in 1.8.0 for some reason

[joshwiens]

It still going to stay in the milestone so I can at the very least remember to cover the use case with a few integration tests.

[ingoe]

This config is working for me using webpack2:

plugins: [ new webpack.LoaderOptionsPlugin({ test: /\.ts$/, options: { bail: true } }); ]

[filipesilva]

I can't seem to get bail: true to be respected in webpack@2.2.1/karma-webpack@2.0.3.

Instead, when I run Karma with --single-run, I'm adding this plugin to error out:

    plugins: [
      // ...
      {
        apply: (compiler) => {
          compiler.plugin('done', (stats) => {
            if (stats.compilation.errors.length > 0) {
              throw new Error(stats.compilation.errors.map((err) => err.message || err));
            }
          });
        }
      }
    ]

[joshwiens]

I've moved this into the org maintainers priority list. One of us, most likely me will get this sorted and out in 2.0.4

[filipesilva]

Hey that's nice to hear, thank you!

[yagudaev]

Having the same issue. It is tied to: webpack/webpack#708.

For us our CI server fails on trying to load phantomjs but still shows the tests pass. See karma-runner/karma-phantomjs-launcher#120

Turns out it is Karma that swallows those errors, I created a PR for it: karma-runner/karma#2672

You can try it locally by using my fork:

yarn remove karma
yarn add nano3labs/karma.git#bail-on-load-error

[alexander-akait]

/cc @d3viant0ne Do I right believe that this problem exists in all loaders?

[joshwiens]

Some, others have hacks in place to work around the issue.

[vitalii]

can reproduce this in 2.0.4 version with tslint-loader

[nemtsov]

We're having the same issue and I can confirm that setting bail: false in the webpack's config makes karma exit with a non-zero error code.

The specific error that was an import to a file that didn't exist; with bail: true in our webpack config.

Versions:

• node: v8.9.1
• npm: 5.5.1
• webpack@3.8.1
• karma@1.7.1
• karma-webpack@2.0.5

[aj-r]

This is still not working with karma-wepack@3.0.0, karma@2.0.2, webpack@4.6.0. Setting bail: true has no effect when running karma. It does work when running webpack-dev-server, though.

This is really annoying in singleRun mode because I would expect the process to exit if the build fails. Since this doesn't happen, our CI builds hang indefinitely if an error occurs. I though this issue was top priority - what happened?

[aj-r]

I also tried setting watch: false in my webpack config, but that also had no effect.

It seems like karma-webpack always runs webpack in watch mode no matter what. I think it should only use watch mode if singleRun is false. Or at the very least, respect the watch setting if the config explicitly sets it.

[PhilippMeissner]

👍 Facing this issue as well :/

[stewsters]

I am also having this issue.

[ertrzyiks]

I'm facing this issue as well. We use require.context to load test files.

I have compilation error available here in err https://github.com/webpack-contrib/karma-webpack/blob/2bb71f53d4957c75599bb1e5165445324194a4ff/src/karma-webpack.js#L192

But the done hook is never called here: https://github.com/webpack-contrib/karma-webpack/blob/2bb71f53d4957c75599bb1e5165445324194a4ff/src/karma-webpack.js#L110

What kinda worked in my case was adding

compiler.plugin('failed', function (err) {
  throw err
})

I need to pause my investigation for now, will try to create a small repo to reproduce the problem I experience later this week.

[ertrzyiks]

I've prepared a minimal repo where you can reproduce the issue.

https://github.com/ertrzyiks/karma-webpack-failed-compilation-example

[teogeos]

Could we have an update on this issue? At some point it was assigned, supposed to go out in 2.0.4, but then it was unassigned. It still has a hotlist label. Is there any plan to fix this issue?

[w4-sglim]

Do you have any update on this issue?

[Ivaylo-Lafchiev]

Is there any workaround for this for Webpack 4? The plugins mentioned previously don't seem to work for me -- build completely hangs on any webpack compilation error as previously described and makes CI a total pain to deal with.

"webpack": "^4.20.2",
"karma-webpack": "^3.0.0",
"karma": "^3.1.1"

[teogeos]

@Ivaylo-Lafchiev I've been using this plugin lately:

class ExitOnErrorWebpackPlugin {
  apply(compiler) {
    compiler.hooks.done.tap("ExitOnErrorWebpackPlugin", stats => {
      if (stats && stats.hasErrors()) {
        stats.toJson().errors.forEach(err => {
          console.error(err);
        });
        process.exit(1);
      }
    });
  }
}

Hope it helps.

[Ivaylo-Lafchiev]

@Ivaylo-Lafchiev I've been using this plugin lately:

class ExitOnErrorWebpackPlugin {
  apply(compiler) {
    compiler.hooks.done.tap("ExitOnErrorWebpackPlugin", stats => {
      if (stats && stats.hasErrors()) {
        stats.toJson().errors.forEach(err => {
          console.error(err);
        });
        process.exit(1);
      }
    });
  }
}

Hope it helps.

Appreciate the reply, but this isn't suitable for our use case as karma runs as part of a gulp pipeline and this would just exit the entire pipeline as opposed to move onto the next task.
I have, however, found a workaround for my problem -- I stumbled onto the Gitlab CE repository, which also uses Webpack 4, karma-webpack & the test_index methodology and after some trial & error discovered they were doing this in their karma config:

// disable problematic options
webpackConfig.entry = undefined;
webpackConfig.mode = 'development';
webpackConfig.optimization.nodeEnv = false;
webpackConfig.optimization.runtimeChunk = false;
webpackConfig.optimization.splitChunks = false;

Specifically, webpackConfig.mode = 'development' seems to solve it. Unfortunately, karma will still go on to run the tests even after webpack fails to compile but at least the process exits gracefully now.
Hope this helps someone.

[trusktr]

Improving on @teogeos's comment, if you'd rather have Webpack output its colored text to the console before exiting, then you can do this instead:

new (class ExitOnErrorWebpackPlugin {
    apply(compiler) {
        compiler.hooks.done.tap('ExitOnErrorWebpackPlugin', stats => {
            if (stats && stats.hasErrors()) {
                // Exit in the next microtask, so that Webpack has a chance to write to stderr
                Promise.resolve().then( () => process.exit(1) )
            }
        })
    }
})(),

[neutraali]

Note: Sometimes (for example, for missing files) you will never reach the done -stage in this particular case. You can listen for the failed -hook in these cases:

class FailBailPlugin {
	apply(compiler) {
		compiler.hooks.failed.tap('FailBailPlugin', (error) => {
			console.error(error);
			process.exit(1);
		});
	}
}

[codymikol]

As karma is now deprecated and coming up on EOL, we are no longer planning on any significant enhancements to this project and are instead going to focus on security updates, stability, and a migration path forward as karma's lifecycle comes to an end.

Thank you for supporting and using this project!