Using --bail makes module build errors more cryptic. #711

redfin-sasha-aickin · 2015-01-22T23:17:36Z

We use --bail so that webpack will report errors to our build script (without --bail, it doesn't give an error exit code).

Unfortunately, when you use --bail, the error result from unparseable JavaScript loses the line that tells you what file the error occurred in.

Example output without --bail:

Hash: 91ed442d775c1a722525
Version: webpack 1.4.13
Time: 3094ms
                                        Asset    Size  Chunks             Chunk Names
<snip>
    + 286 hidden modules

ERROR in ./pages/MyPage.js
Module build failed: Error: Parse Error: Line 7: Unexpected token ;
    at throwError (/Users/sashaaickin/code/main/corvair/node_modules/jsx-loader/node_modules/react-tools/node_modules/jstransform/node_modules/esprima-fb/esprima.js:2644:21)
    at throwUnexpected (/Users/sashaaickin/code/main/corvair/node_modules/jsx-loader/node_modules/react-tools/node_modules/jstransform/node_modules/esprima-fb/esprima.js:2706:9)
<snip>
    at parseProgramElement (/Users/sashaaickin/code/main/corvair/node_modules/jsx-loader/node_modules/react-tools/node_modules/jstransform/node_modules/esprima-fb/esprima.js:6185:16)
 @ ./target-entrypoints/MyPageEntry.js 4:17-68

With --bail, the output looks like:

ModuleBuildError: Module build failed: Error: Parse Error: Line 7: Unexpected token ;
    at throwError (/Users/sashaaickin/code/main/corvair/node_modules/jsx-loader/node_modules/react-tools/node_modules/jstransform/node_modules/esprima-fb/esprima.js:2644:21)
    at throwUnexpected (/Users/sashaaickin/code/main/corvair/node_modules/jsx-loader/node_modules/react-tools/node_modules/jstransform/node_modules/esprima-fb/esprima.js:2706:9)
<snip>
    at /Users/sashaaickin/code/main/corvair/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:270:15
    at runSyncOrAsync (/Users/sashaaickin/code/main/corvair/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:158:12)

Note that without --bail, the file with the syntax error (MyPage.js) is named, but not in the latter. This makes it hard to debug problems that come from our build script, because the error log does not tell us what file the problem is in.

The text was updated successfully, but these errors were encountered:

sapegin · 2015-03-23T14:46:23Z

Even more cryptic with loaders such as eslint-loader.

Without --bail:

Hash: 396f0bfb9d565b6f60f0
Version: webpack 1.7.3
Time: 1157ms
    + 1 hidden modules

ERROR in ./app/app.js

  5:78  error  Missing semicolon  semi

✖ 1 problem (1 error, 0 warnings)


ERROR in ./app/app.js
Module build failed: Error: Module failed because of a eslint error.
    at lint (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/eslint-loader/index.js:54:15)
    at Object.module.exports (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/eslint-loader/index.js:80:3)

With --bail:

ModuleBuildError: Module build failed: Error: Module failed because of a eslint error.
    at lint (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/eslint-loader/index.js:54:15)
    at Object.module.exports (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/eslint-loader/index.js:80:3)
    at DependenciesBlock.onModuleBuildFailed (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:303:19)
    at nextLoader (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:263:31)
    at /Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:285:15
    at runSyncOrAsync (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:171:4)
    at nextLoader (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/webpack/node_modules/webpack-core/lib/NormalModuleMixin.js:283:3)
    at Storage.finished (/Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:38:16)
    at evalmachine.<anonymous>:272:14
    at /Users/admin/Dropbox/Projects/Misc/deliveryhero-test/node_modules/webpack/node_modules/enhanced-resolve/node_modules/graceful-fs/graceful-fs.js:102:5
    at Object.oncomplete (evalmachine.<anonymous>:108:15)

ctumolosus · 2015-06-03T02:45:20Z

I find this to be an undesirable effect as well.

josephfinlayson · 2015-09-29T14:20:48Z

Any pointers on how to fix this? We're having @sapegin 's problem.

jhuntoo · 2016-03-04T11:09:17Z

Any updates on this ?

This is a real pain, --bail is needed so that CI builds will fail when they should. However tslint-loader will not tell why it's failing.

This has been reported here : wbuchwalter/tslint-loader#18
and here: PatrickJS/PatrickJS-starter#374

For authors of loaders looking for a workaround, see how eslint-loader resolved this webpack-contrib/eslint-loader#53, by returning the errors or warnings in the exception message itself.

e.g. https://github.com/MoOx/eslint-loader/blob/master/index.js#L73

jhuntoo · 2016-03-04T11:50:47Z

AN issue with the workaround, when a loader returns an error and webpack bails, only the first error returns which could be tedious if you have a lot of errors and have to keep re running the build. Is there a way that webpack could allow a loader to report all errors and bail after all errors are known ?

…l bug webpack/webpack#711

martpie · 2016-07-20T08:13:00Z

Hello ! Any news on this ?

PhiLhoSoft · 2016-08-01T16:27:26Z

I don't have this problem. Either it depends on config (I also use eslint-loader), or it has been fixed.

I have:

Hash: df6a9e09957b40770a92
Version: webpack 1.13.1
Time: 38200ms
[0] multi vendor 232 bytes {1} [built]
factory:0ms building:1ms = 1ms
[187] ./Project/app/scripts/features/settings ^./.*.html$ 729 bytes {0} [built]
... -> factory:253ms building:121ms
+ 232 hidden modules

ERROR in ./Project/app/scripts/services/slug.js

D:\Sources\Project\app\scripts\services\slug.js
185:15 error Missing semicolon semi

✖ 1 problem (1 error, 0 warnings)

on Windows 10.
My build launches webpack --bail --progress --profile

khronic · 2016-10-04T15:56:55Z

Hey guys just wondering if there is any new update on this item?

wyattjoh · 2016-11-09T14:27:51Z

Also experiencing the same issue here.

domenkozar · 2017-02-23T12:53:42Z

Same here https://travis-ci.org/input-output-hk/cardano-sl/jobs/204533248

jmitchell · 2017-02-23T18:53:14Z

Here's a silly workaround. Given a webpack call without --bail called $RUN_WP,

$RUN_WP && $RUN_WP --bail

The first run gives you the detailed feedback about the error, and the second ensures you get a non-zero exit code when there's an error. This shouldn't be necessary, and is a hack.

See webpack/webpack#711 (comment)

timraasveld · 2017-05-22T13:09:11Z

Based on @jmitchell's suggestion, I do the following to enable Bash command chaining, but only print the pretty (non --bail) error if it fails.

(webpack && webpack --bail > /dev/null 2>&1) && run_command_that_only_runs_on_webpack_success

McGiogen · 2018-04-04T13:54:42Z

Any progress about this request? We will never build two times just to improve the logs...

Janpot · 2018-04-07T14:11:19Z

I'm trying to reproduce this but adding the --bail flag makes no difference for me. Is this happening on the latest version? Does anybody have an example of a repo where this happens?

ooflorent · 2018-05-09T06:45:33Z

I'm closing this issue since the problem is not reproducible using webpack 4 and webpack 3 is on maintenance mode.

…l bug webpack/webpack#711

pstoica mentioned this issue Jul 27, 2015

Exit process with code 1 if lint errors webpack-contrib/eslint-loader#53

Closed

bebraw added the bug label Nov 15, 2015

alexch mentioned this issue Feb 3, 2016

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

Closed

This was referenced Mar 4, 2016

Tslint errors are not displayed when using --bail option in Webpack wbuchwalter/tslint-loader#18

Closed

Running production builds resolves in tslint errors PatrickJS/PatrickJS-starter#374

Closed

dsebastien mentioned this issue Mar 4, 2016

Add bail option to production once webpack issue is fixed dsebastien/angularjs-webpack-starter#53

Closed

jhuntoo added a commit to jhuntoo/angular2-webpack-starter that referenced this issue Mar 6, 2016

Bump tslint-loader to 2.1.3 which includes a workaround for the --bai…

372eb30

…l bug webpack/webpack#711

jhuntoo mentioned this issue Mar 6, 2016

Bump tslint-loader to 2.1.3 PatrickJS/PatrickJS-starter#387

Merged

domenkozar mentioned this issue Feb 23, 2017

Move to LTS Haskell 8.2 input-output-hk/cardano-sl#43

Merged

jmitchell added a commit to input-output-hk/cardano-sl that referenced this issue Feb 23, 2017

[CSL-818] Webpack hack to get detailed error and exit code

558307e

See webpack/webpack#711 (comment)

ooflorent closed this as completed May 9, 2018

DevStar0804 added a commit to DevStar0804/star that referenced this issue Dec 8, 2020

Bump tslint-loader to 2.1.3 which includes a workaround for the --bai…

c6c7ac2

…l bug webpack/webpack#711

DevStar0804 added a commit to DevStar0804/star that referenced this issue Aug 2, 2021

Bump tslint-loader to 2.1.3 which includes a workaround for the --bai…

4a2e2cf

…l bug webpack/webpack#711

eagerbeaver0353 added a commit to eagerbeaver0353/invoice-app-electron-angular that referenced this issue May 11, 2023

Bump tslint-loader to 2.1.3 which includes a workaround for the --bai…

9f8e83e

…l bug webpack/webpack#711

leonhiat added a commit to leonhiat/MFE-starter that referenced this issue Oct 31, 2023

Bump tslint-loader to 2.1.3 which includes a workaround for the --bai…

10be129

…l bug webpack/webpack#711

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Using --bail makes module build errors more cryptic. #711

Using --bail makes module build errors more cryptic. #711

redfin-sasha-aickin commented Jan 22, 2015

sapegin commented Mar 23, 2015

ctumolosus commented Jun 3, 2015

josephfinlayson commented Sep 29, 2015

jhuntoo commented Mar 4, 2016

jhuntoo commented Mar 4, 2016

martpie commented Jul 20, 2016

PhiLhoSoft commented Aug 1, 2016

khronic commented Oct 4, 2016

wyattjoh commented Nov 9, 2016

domenkozar commented Feb 23, 2017 •

edited

jmitchell commented Feb 23, 2017

timraasveld commented May 22, 2017 •

edited

McGiogen commented Apr 4, 2018

Janpot commented Apr 7, 2018

ooflorent commented May 9, 2018

Using --bail makes module build errors more cryptic. #711

Using --bail makes module build errors more cryptic. #711

Comments

redfin-sasha-aickin commented Jan 22, 2015

sapegin commented Mar 23, 2015

ctumolosus commented Jun 3, 2015

josephfinlayson commented Sep 29, 2015

jhuntoo commented Mar 4, 2016

jhuntoo commented Mar 4, 2016

martpie commented Jul 20, 2016

PhiLhoSoft commented Aug 1, 2016

khronic commented Oct 4, 2016

wyattjoh commented Nov 9, 2016

domenkozar commented Feb 23, 2017 • edited

jmitchell commented Feb 23, 2017

timraasveld commented May 22, 2017 • edited

McGiogen commented Apr 4, 2018

Janpot commented Apr 7, 2018

ooflorent commented May 9, 2018

domenkozar commented Feb 23, 2017 •

edited

timraasveld commented May 22, 2017 •

edited