Webpack client does not throw error code when build failed

[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]

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]

--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]

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!

[nelix]

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

[Turbo87]

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

[sokra]

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

[Turbo87]

@sokra 👍 for that

[marr]

Closed but this is still not default behavior..

[sokra]

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]

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

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]

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]

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

[alexch]

related:
andreypopp/typescript-loader#21
#708
#711

[cerisier]

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]

👍 @alexch

[jhnns]

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?

[sepo-one]

--bail does not help when throwing an error from loader

[blordpluto]

It looks like the last comment in this thread is still an issue. I have --bail set to true. A CSS loader is erroring. And a CI build is failing without aborting. Thus a false positive for success of the build. This is very confusing for CI. Has this really not been addressed for three years? 🤔

I would like to be able to set an initial loader for single-run compile that catches any errors from the subsequent loaders, and then terminates the entire process. Something similar to the code at the top of this thread. But I don't see any way to hook into other loader's errors in the loader interface. Thanks in advance for any help.

[Yankovsky]

Throwing error from loader results in successful build with warning.

[sokra]

It's a warning so it doesn't result in an exit code.

But it probably shouldn't be a warning.

[Yankovsky]

Seems like if schema validation errors is wrapped in the same warning.

[Yankovsky]

@sokra Do you need help with that issue? Example repo?

[sokra]

If you want to you can send a PR. The problem is that elements in a "ContextModule" are considered as optional. That should be changed for webpack 5.

Look for ContextElementDependency and ContextHelper

[sokra]

fixed by #11327