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 · 44 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@happypoulp

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

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

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Jan 21, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@happypoulp

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

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

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Jan 22, 2015

Member

--bail

Member

sokra commented Jan 22, 2015

--bail

@happypoulp

This comment has been minimized.

Show comment
Hide comment
@happypoulp

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

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

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Jan 22, 2015

Member

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

Member

sokra commented Jan 22, 2015

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

@happypoulp

This comment has been minimized.

Show comment
Hide comment
@happypoulp

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

This comment has been minimized.

Show comment
Hide comment
@nelix

nelix Jan 22, 2015

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

nelix commented Jan 22, 2015

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

@Turbo87

This comment has been minimized.

Show comment
Hide comment
@Turbo87

Turbo87 Feb 11, 2015

Contributor

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

Contributor

Turbo87 commented Feb 11, 2015

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

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Feb 13, 2015

Member

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

Member

sokra commented Feb 13, 2015

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

@Turbo87

This comment has been minimized.

Show comment
Hide comment
@Turbo87

Turbo87 Feb 13, 2015

Contributor

@sokra 👍 for that

Contributor

Turbo87 commented Feb 13, 2015

@sokra 👍 for that

@marr

This comment has been minimized.

Show comment
Hide comment
@marr

marr May 21, 2015

Closed but this is still not default behavior..

marr commented May 21, 2015

Closed but this is still not default behavior..

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra May 21, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@aindlq

aindlq 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

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

This comment has been minimized.

Show comment
Hide comment
@TiddoLangerak

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

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

This comment has been minimized.

Show comment
Hide comment
@igl

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

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

This comment has been minimized.

Show comment
Hide comment
@kilianc

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

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

This comment has been minimized.

Show comment
Hide comment
@alexch

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

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.

@alexch

This comment has been minimized.

Show comment
Hide comment
@cerisier

This comment has been minimized.

Show comment
Hide comment
@cerisier

cerisier 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 ?

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

This comment has been minimized.

Show comment
Hide comment
@asagage

asagage commented Feb 10, 2016

👍 @alexch

@jhnns

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Feb 10, 2016

Member

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?

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?

gpbl added a commit to shoutit/shoutit-web that referenced this issue Feb 10, 2016

@giorgiosironi

This comment has been minimized.

Show comment
Hide comment
@giorgiosironi

giorgiosironi Mar 1, 2016

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.

giorgiosironi commented Mar 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cjb

cjb Mar 8, 2016

@giorgiosironi Yep, just did exactly this. :(

cjb commented Mar 8, 2016

@giorgiosironi Yep, just did exactly this. :(

@nathancahill

This comment has been minimized.

Show comment
Hide comment
@nathancahill

nathancahill Mar 14, 2016

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

nathancahill commented Mar 14, 2016

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

@StephanBijzitter

This comment has been minimized.

Show comment
Hide comment
@StephanBijzitter

StephanBijzitter Mar 29, 2016

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

StephanBijzitter commented Mar 29, 2016

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

@JustFly1984

This comment has been minimized.

Show comment
Hide comment
@JustFly1984

JustFly1984 Mar 29, 2016

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

JustFly1984 commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kemsky

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

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

This comment has been minimized.

Show comment
Hide comment
@igl

igl Mar 30, 2016

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

igl commented Mar 30, 2016

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

@kemsky

This comment has been minimized.

Show comment
Hide comment
@kemsky

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

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 added a commit to Restuta/webpack-howto that referenced this issue Apr 6, 2016

added --bail option
Surprisingly this is not default behaviour and simple gotcha with webpack 1 (see webpack/webpack#708 for mor edetails)
@cjwilliams

This comment has been minimized.

Show comment
Hide comment
@cjwilliams

cjwilliams Oct 7, 2016

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?

cjwilliams commented Oct 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@wonderbeyond

wonderbeyond Oct 12, 2016

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

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

wonderbeyond commented Oct 12, 2016

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

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

@jhnns

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Oct 19, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@StephanBijzitter

StephanBijzitter Oct 19, 2016

That's only two years too late...

StephanBijzitter commented Oct 19, 2016

That's only two years too late...

@jhnns

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Oct 21, 2016

Member

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

Member

jhnns commented Oct 21, 2016

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

@StephanBijzitter

This comment has been minimized.

Show comment
Hide comment
@StephanBijzitter

StephanBijzitter Oct 21, 2016

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.

StephanBijzitter commented Oct 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@StevenIseki

StevenIseki Nov 8, 2016

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.

StevenIseki commented Nov 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@PhiLhoSoft

PhiLhoSoft Nov 9, 2016

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

PhiLhoSoft commented Nov 9, 2016

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

@urbanhusky

This comment has been minimized.

Show comment
Hide comment
@urbanhusky

urbanhusky Nov 16, 2016

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.

urbanhusky commented Nov 16, 2016

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.

@tao12345666333

This comment has been minimized.

Show comment
Hide comment
@tao12345666333

tao12345666333 commented Dec 15, 2016

Thanks all.

@simnalamburt simnalamburt referenced this issue Jan 10, 2017

Closed

Resolve false positive from Travis CI #41

3 of 3 tasks complete

simnalamburt added a commit to libreirc/libreirc that referenced this issue Jan 10, 2017

simnalamburt added a commit to simnalamburt/pen that referenced this issue Jan 10, 2017

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

simnalamburt added a commit to libreirc/libreirc that referenced this issue Jan 11, 2017

BWortman pushed a commit to fusionalliance/autorenter-angular1 that referenced this issue Jan 23, 2017

Add missing package the build caught!
Also, webpack build failed.. issue with webpack 1 not exiting properly.
webpack/webpack#708

@adrianq adrianq referenced this issue Apr 18, 2017

Closed

Fixing travis for npm #588

0 of 3 tasks complete
@sepo-one

This comment has been minimized.

Show comment
Hide comment
@sepo-one

sepo-one Jun 8, 2017

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

sepo-one commented Jun 8, 2017

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

richvdh added a commit to vector-im/riot-web that referenced this issue Aug 8, 2017

Make webpack exit non-zero on error
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/riot-web that referenced this issue Aug 8, 2017

Make webpack exit non-zero on error
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment