Webpack client does not throw error code when build failed

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.

Author: Fantashit

14 thoughts on “Webpack client does not throw error code when build failed

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

  2. 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 ^^

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

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

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

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

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

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

Comments are closed.