Webpack client does not throw error code when build failed #708

Closed
happypoulp opened this Issue Jan 21, 2015 · 43 comments

Projects

None yet
@happypoulp

Hi,

I'd like to know when a build failed using the webpack client (because of a module not found for example). Right now, it seems that the client is outputting the error to the console but the status code of the webpack client process is 0 (success).

Is it the normal behavior? I can imagine that when using the watch option we don't want the process to end on a build failure but without the option, could the client terminate with a status != 0?

I'd like to avoid to search for "ERROR" inside the client output to determine that the build failed.

Thanks.

@happypoulp

I found a way to get the desired result using the 'done' plugin:

// ...
plugins: [
    // ...
    function()
    {
        this.plugin("done", function(stats)
        {
            if (stats.compilation.errors && stats.compilation.errors.length)
            {
                console.log(stats.compilation.errors);
                process.exit(1);
            }
            // ...
        });
    }
    // ...
],
// ...

Is this the correct way to go?

Thanks.

@jhnns
Member
jhnns commented Jan 21, 2015

That is valid approach (you could also just throw an error :)).

And yes, I agree with you: webpack should exit with error code 1 when a build error occurred and watch is not active. I remember some discussion with @sokra about this topic ^^

@happypoulp

Ok, thanks for the quick reply!

I'll go with this solution. However, going through a throw new Error(...) produce a little bit more output (with the stack trace of the error) that I do not need.

For the records, here is the version that avoids exiting the client process when the --watch option is present:

// ...
plugins: [
    // ...
    function()
    {
        this.plugin("done", function(stats)
        {
            if (stats.compilation.errors && stats.compilation.errors.length && process.argv.indexOf('--watch') == -1)
            {
                console.log(stats.compilation.errors);
                process.exit(1); // or throw new Error('webpack build failed.');
            }
            // ...
        });
    }
    // ...
],
// ...

I'll leave the issue open for now since it would be nice to have webpack client exit with error code 1 on build failure. Feel free to cancel it if you think the present solution is enough.

@sokra
Member
sokra commented Jan 22, 2015

--bail

@happypoulp

@sokra Please could you detail the use of the --bail option?

I tried: ./node_modules/.bin/webpack --progress --colors --config --bail conf/webpack.config.js

the output seems to be truncated but the client does not exit with an error code.

@sokra
Member
sokra commented Jan 22, 2015

Try ./node_modules/.bin/webpack --progress --colors --config conf/webpack.config.js --bail

@happypoulp

Works like charm!

My bad, I just noticed that this option was well documented, but I didn't see it in the client options page and had not understood the relation between config options and client options.

Thanks for pointing it!

@happypoulp happypoulp closed this Jan 22, 2015
@nelix
nelix commented Jan 22, 2015

I would not exactly say this is well documented, but vaguely referenced.

@Turbo87
Contributor
Turbo87 commented Feb 11, 2015

@sokra could you point out why --bail is not the default behavior in non-watch mode?

@sokra
Member
sokra commented Feb 13, 2015

I can change it with the next major version...

@Turbo87
Contributor
Turbo87 commented Feb 13, 2015

@sokra πŸ‘ for that

@ChimeraCoder ChimeraCoder referenced this issue in andreypopp/typescript-loader Apr 22, 2015
Open

Throw error code when build fails #21

@marr
marr commented May 21, 2015

Closed but this is still not default behavior..

@sokra
Member
sokra commented May 21, 2015

Closed but this is still not default behavior..

It's default in the webpack-2 branch. That's the next major version. It's a breaking change...

@aindlq
aindlq commented May 21, 2015

@sokra I've noticed that --bail flag doesn't work in 1.9.*
And it seems some other users had similar experience -http://stackoverflow.com/a/29510310/124722

@TiddoLangerak

As a temporary workaround I've created a small plugin based on the code from @happypoulp above that will exit with error code 1 when the build fails in single-run mode. You can find it here.

@igl
igl commented Aug 2, 2015

I was just trying to send webpacks stdout to /dev/null because i do not care about the build report.
However without --bail stderr seems to remain empty.

@kilianc
kilianc commented Dec 23, 2015

I don't understand why --bail is related to proper exit code. If there is an error exit code needs to be > 0, bail or not, and bail should not be default behavior.

@alexch
alexch commented Jan 27, 2016

@kilianc πŸ‘

This discussion (and code) is confounding at least 3 different cases:

  1. return a non-zero error code on failure
  2. exit immediately on failure (is this what --bail is supposed to mean?)
  3. how verbose should error output be

Regardless of 2 and 3, if an error occurred during the build, then when webpack exits, it must exit with a non-zero error code. Otherwise this is unusable in a continuous build script.

That's not a breaking change. It's fixing a major bug.

Whether --bail should be default behavior is also interesting but a completely different question.

@cerisier
cerisier commented Feb 9, 2016

100% agree with @alexch

Just had major headache finding out why deployed build was broken although CI showed all build passed...

What is the state on this ? Can we help in any way ?

@asagage
asagage commented Feb 10, 2016

πŸ‘ @alexch

@jhnns
Member
jhnns commented Feb 10, 2016

I can change it with the next major version...

@sokra what's the state for webpack 2 regarding this issue? Wouldn't a non-zero exit code be good?

@thekarel thekarel referenced this issue in guardian/tagmanager Feb 18, 2016
Closed

Fail CI build if `npm build` / Webpack fails #186

@giorgiosironi

This is a serious bug, πŸ‘ to @cerisier and @alexch. You're going to deploy a bundle containing

   (function webpackMissingModule() { throw new Error("Cannot find module \"...\""); }());                                                             

without finding out until tests are executed against it.

@cjb
cjb commented Mar 8, 2016

@giorgiosironi Yep, just did exactly this. :(

@nathancahill

Just had this happen to me. +1 for non-zero exit code.

@StephanBijzitter

Same happened here... why is this not fixed @sokra ?

@JustFly1984

had the same issue with webpack exiting without proper exit code

fixed this by adding to webpack config:

plugins: [
    function() {
      this.plugin("done", function(stats) {
        if (stats.compilation.errors && stats.compilation.errors.length &&
process.argv.indexOf("--watch") == -1) {
          console.log(stats.compilation.errors);
          process.exit(1);
        }
      });
    }]

2016-03-29 21:55 GMT+08:00 Stephan Bijzitter <notifications@github.com>:

> Same happened here... why is this not fixed @sokra
> <https://github.com/sokra> ?
>
> β€”
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub
> <https://github.com/webpack/webpack/issues/708#issuecomment-202904903>
>
@kemsky
kemsky commented Mar 30, 2016

This is partial fix, logging stats.compilation.errors is ugly and has various issues when used with karma or gulp. I wish there was an appropriate option for this.

@igl
igl commented Mar 30, 2016

@kemsky Printing the errors into stderr using console.error() does not help it?

@kemsky
kemsky commented Mar 31, 2016

@igl, error objects contain different sets of properties depending on context (karma, gulp, standalone), error messages are not properly formatted in this case, you loose original webpack messages, because process is interrupted before webpack writes to stdout, configuration become bloated, gulp task can not exit correctly (forget to signal async completion?) and etc.

@Restuta Restuta added a commit to Restuta/webpack-howto that referenced this issue Apr 6, 2016
@Restuta Restuta added --bail option
Surprisingly this is not default behaviour and simple gotcha with webpack 1 (see webpack/webpack#708 for mor edetails)
d7d02f2
@pirelenito pirelenito added a commit to saguijs/sagui that referenced this issue May 28, 2016
@pirelenito pirelenito Fix: Webpack by default always exits with status code 0
This is a known β€œissue” that will change on Webpack 2, but for now we need to use the `--bail` flag.

More information at: webpack/webpack#708 (comment)
df15e3d
@PhiLhoSoft

@aindlq It is also my experience with Webpack 1.12 on Windows 10. echo %errorlevel% shows 0 if I use the command line webpack --bail --progress --profile and have an error (eslint-loader reporting a missing semi-colon, for example).

@TiddoLangerak Your plugin works fine, thank you. In the above case, the reported errorlevel is 1.
I was surprised I only had to put the name of the plugin in the list of plugins. All other plugins I used in my configuration use a new PluginName() instead.

About the above remarks on console.log(errors), webpack-fail-plugin just exits and the errors are correctly reported on the console.

@Zinssmeister Zinssmeister referenced this issue in mipearson/webpack-rails Aug 2, 2016
Merged

Fix for flawless heroku deploy #44

@razorcd
razorcd commented Aug 15, 2016

If you start the webpack build from a gulp task and webpack fails then gulp will still exit with 0. Even if using the --bail flag.

gulp.task('build-js', function () {
    webpack(webpackConfig).run(...);
});

Solution: use webpack-fail-plugin and the gulp task will exit with 1.

@alexch alexch referenced this issue in TiddoLangerak/webpack-fail-plugin Aug 17, 2016
Open

webpack-fail-plugin should be a PR, not a plugin #9

@svarnoi420
svarnoi420 commented Aug 31, 2016 edited

This my solution from here http://webpack.github.io/docs/node.js-api.html#error-handling

And I don't used webpack-fail-plugin.

I used gulp-util for format webpack log to gulp format.

node-notifier just optional.

const gulp     = require('gulp'); // version 3.9.1
const gutil    = require('gulp-util'); // version 3.0.7
const webpack  = require('webpack'); // version 1.13.1
const notifier = require('node-notifier'); // version 4.6.0

let webpackConfig = require('../webpack.config.js');
let statsLog      = {
    colors: true,
    reasons: true
};

gulp.task('scripts', (done) => {
    // run webpack
    webpack(webpackConfig, onComplete);

    function onComplete(error, stats) {
        if (error) { // fatal error
            onError(error);
        } else if ( stats.hasErrors() ) { // soft error
            onError( stats.toString(statsLog) );
        } else {
            onSuccess( stats.toString(statsLog) );
        }
    }

    function onError(error) {
        let formatedError = new gutil.PluginError('webpack', error);

        notifier.notify({
            title: `Error: ${formatedError.plugin}`,
            message: formatedError.message
        });

        done(formatedError);
    }

    function onSuccess(detailInfo) {
        gutil.log('[webpack]', detailInfo);
        done();
    }
});
@cjwilliams
cjwilliams commented Oct 7, 2016 edited

Are there still plans/desires to make non-zero exit codes standard? If so, should we re-open this issue or link to something with a more updated status on the issue?

@wonderbeyond
wonderbeyond commented Oct 12, 2016 edited

I can change it with the next major version...

It's something must! Error with status=0 is evil!

@jhnns
Member
jhnns commented Oct 19, 2016

I agree with all of you. I don't understand what the rationale behind the current behavior was.

However, since we're about to finish webpack 2 (which will exit with a non-zero exit code by default), we won't add any non-critical things to webpack 1 anymore.

@StephanBijzitter

That's only two years too late...

@goller goller referenced this issue in influxdata/chronograf Oct 20, 2016
Merged

Fix webpack exit code to actually work. #260

@jhnns
Member
jhnns commented Oct 21, 2016

If you want to speed up development, funding helps more than complaining.

@StephanBijzitter

That would not fix the priorities.

Somehow, webpack 2 is getting more priority than this bug. This is webpack, a command-line build tool that always exits with status 0, which makes it largely useless unless you fix it manually after googling. If you guys had more money, perhaps webpack 2 would arrive a month sooner, but this bug would still be in the webpack 1 releases.

I'd even just fix it myself and submit a pr, but you wouldn't even want to merge a bugfix as you believe it's a breaking change. No, it's not: it's fixing a broken tool.

@StevenIseki

Just use the --bail option until webpack 2 comes out as sokra mentioned, it works well for me, and allows me to see errors in CI builds.

@PhiLhoSoft

@StevenIseki Looks like you haven't read the whole thread...

@reconbot reconbot referenced this issue in bustlelabs/shep Nov 14, 2016
Closed

Dont deploy when webpack fails #112

@urbanhusky

I actually think that this isn't a bug. During development, with hot module replacement, you wouldn't want the webpack dev server to crash whenever you've created invalid TypeScript etc.

Certainly, you would want a non-zero error code for production builds (which do not utilise the webpack-dev server). Personally, I'm fine with adding the workaround/hack to my production configuration.

@TiddoLangerak TiddoLangerak referenced this issue in TiddoLangerak/webpack-fail-plugin Nov 21, 2016
Closed

Please deprecate #11

@tao12345666333

Thanks all.

@simnalamburt simnalamburt added a commit to libreirc/libreirc that referenced this issue Jan 10, 2017
@simnalamburt simnalamburt Apply 'webpack-fail-plugin' plugin
Closes #41

Reference:
  webpack/webpack#708
99083a8
@simnalamburt simnalamburt referenced this issue in libreirc/libreirc Jan 10, 2017
Merged

Apply 'webpack-fail-plugin' plugin #45

@simnalamburt simnalamburt added a commit to simnalamburt/pen that referenced this issue Jan 10, 2017
@simnalamburt simnalamburt Apply 'webpack-fail-plugin' plugin
Webpack can emit false positive in few corner cases without this plugin.
This issue has been resolved in Webpack 2.

Reference:
  webpack/webpack#708
de92d29
@simnalamburt simnalamburt added a commit to libreirc/libreirc that referenced this issue Jan 11, 2017
@simnalamburt simnalamburt Apply 'webpack-fail-plugin' plugin
Closes #41

Reference:
  webpack/webpack#708
10f3022
@BWortman BWortman pushed a commit to fusionalliance/autorenter-angular1 that referenced this issue Jan 23, 2017
@rclanan rclanan Add missing package the build caught!
Also, webpack build failed.. issue with webpack 1 not exiting properly.
webpack/webpack#708
606c4dc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment