Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
happypoulp opened this issue Jan 21, 2015 · 51 comments
Closed

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

happypoulp opened this issue Jan 21, 2015 · 51 comments
Labels
Projects

Comments

@happypoulp
Copy link

@happypoulp happypoulp commented Jan 21, 2015

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
Copy link
Author

@happypoulp happypoulp commented Jan 21, 2015

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
Copy link
Member

@jhnns 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
Copy link
Author

@happypoulp happypoulp commented Jan 21, 2015

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
Copy link
Member

@sokra sokra commented Jan 22, 2015

--bail

@happypoulp
Copy link
Author

@happypoulp happypoulp commented Jan 22, 2015

@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
Copy link
Member

@sokra sokra commented Jan 22, 2015

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

@happypoulp
Copy link
Author

@happypoulp happypoulp commented Jan 22, 2015

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
Copy link

@nelix nelix commented Jan 22, 2015

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

@Turbo87
Copy link
Contributor

@Turbo87 Turbo87 commented Feb 11, 2015

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

@sokra
Copy link
Member

@sokra sokra commented Feb 13, 2015

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

@Turbo87
Copy link
Contributor

@Turbo87 Turbo87 commented Feb 13, 2015

@sokra 👍 for that

@marr
Copy link

@marr marr commented May 21, 2015

Closed but this is still not default behavior..

@sokra
Copy link
Member

@sokra 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
Copy link

@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
Copy link

@TiddoLangerak TiddoLangerak commented Jul 21, 2015

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
Copy link

@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
Copy link

@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
Copy link

@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
Copy link

@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
Copy link

@asagage asagage commented Feb 10, 2016

👍 @alexch

@jhnns
Copy link
Member

@jhnns 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?

gpbl added a commit to shoutit/shoutit-web that referenced this issue Feb 10, 2016
@sepo-one
Copy link

@sepo-one sepo-one commented Jun 8, 2017

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

richvdh added a commit to vector-im/element-web that referenced this issue Aug 8, 2017
Pass `--bail` to webpack, so that if we can't find a module, we bail out rather
than deploy a broken version to /develop.

webpack/webpack#708 is somewhat relevant.
richvdh added a commit to vector-im/element-web that referenced this issue Aug 8, 2017
Pass `--bail` to webpack, so that if we can't find a module, we bail out rather
than deploy a broken version to /develop.

webpack/webpack#708 is somewhat relevant.
@blordpluto
Copy link

@blordpluto blordpluto commented Jan 27, 2020

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
Copy link

@Yankovsky Yankovsky commented May 22, 2020

Throwing error from loader results in successful build with warning.
https://i.ibb.co/z2X95B2/2020-05-22-11-39-56-czgtz.jpg

@sokra
Copy link
Member

@sokra sokra commented May 22, 2020

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

But it probably shouldn't be a warning.

@sokra sokra reopened this Jun 2, 2020
@sokra sokra added this to Important in webpack 5 Jun 2, 2020
@Yankovsky
Copy link

@Yankovsky Yankovsky commented Jun 2, 2020

Seems like if schema validation errors is wrapped in the same warning.
http://s.csssr.ru/U02D248T6/2020-06-02-15-47-37-m4mqe_.jpg

@Yankovsky
Copy link

@Yankovsky Yankovsky commented Jun 2, 2020

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

@sokra
Copy link
Member

@sokra sokra commented Jun 2, 2020

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
Copy link
Member

@sokra sokra commented Sep 23, 2020

fixed by #11327

@sokra sokra closed this Sep 23, 2020
@sokra sokra moved this from Important to Done in webpack 5 Sep 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.