Repository navigation
webpack exit code is equal to 0, if typescript build fails #108
Description
When the build fails (i.e. at least one typescript compile error occured), the ts-loader emits an incomplete javascript file and does not propagate the build failure to webpack. When using webpack with the --bail command line option an compile error, should result in an webpack exit code not equal to zero.
Is there another way or option to check if a compile error occured.
Reacted by Damien Rajon, AverageHelper and Kirill Alexander Khalitov
Activity
mpseidel commentedon Nov 18, 2015
+1 - this would be really helpful
@PePe79 theoretically you could use the --noEmitOnError typescript option to get an exit code > 0 but then you only get something like this as an error message
ModuleBuildError: Module build failed: Error: Typescript emitted no output for .../file.tsso none of the helpful ts compiler errors.marcelkottmann commentedon Nov 18, 2015
yes, i tried this already before, but this error message is not really useful.
https://github.com/denvned/webpack-typescript does fail with exit code > 0 on compile error with webpack command line option --bail
But this loader has other issues, so that's not an alternative for us and i would like to go on with ts-loader. But this bug is a blocker for our automated builds.
jbrantly commentedon Nov 18, 2015
Yea, definitely know the need is there. Have you tried
noEmitOnError(even though there are possibly issues with that - #91)?jbrantly commentedon Nov 18, 2015
Wow. I didn't get a lot of sleep and missed your comment on
noEmitOnError. Sorry.denvned commentedon Nov 18, 2015
@PePe79, I would be happy to resolve any issues you have with webpack-typescript: https://github.com/denvned/webpack-typescript/issues
MarkusKramer commentedon Dec 23, 2015
+1 would be really great if this was fixed. as incomplete error messages are obviously a big problem.
EvAlex commentedon Jan 21, 2016
👍 unbeleivable! That's a blocker issue for using with build server!
EvAlex commentedon Jan 21, 2016
@denvned, your loader has the same issue
EvAlex commentedon Jan 21, 2016
Oh yeah, I've managed to fix it. I will create Pull Request and attach explaination there in 6-8 hours.
raybooysen commentedon Jan 21, 2016
or @EvAlex @denvned @jbrantly combine to have a single loader, so we don't have all these disparate loaders. :)
jbrantly commentedon Jan 21, 2016
Always open to PRs. FWIW, I think the correct solution to this is to fix #91 to be more useful and then combine that with
--bailfor the webpack exit code, but since I haven't actually dug in and tried it yet I don't know if there are problems with that approach.TypeStrong#108 added collecting, logging and reporting errors during …
vladimir-rovensky commentedon Jan 29, 2016
FWIW until this is fixed you can use something like webpack-fail-plugin to make your build fail on error.
jbrantly commentedon Jan 30, 2016
OK, I've looked at this in more detail and here is where I've arrived:
According to this, webpack2 should fix the exit code. They are not making the change to webpack1 for backward-compatibility reasons.
I could make a change to ts-loader that would change the exit code in the case of failure. However, I feel like there are some issues with that, namely that a single loader would be taking on the responsibility of changing the exit code when there could be a lot of moving parts in the webpack config. For that reason it would at the very least need to be behind a flag. I could default the flag to "on" which would be a breaking change, and possibly could cause confusion when someone is trying to figure out why their build is all of a sudden failing. Or I could default to "off", which means you fine people looking for this functionality would have to configure it to "on" anyways.
It seems to me a better solution is to recommend the webpack-fail-plugin suggested by @vladimir-rovensky. The source for that plugin seems completely reasonable, and I just tried it myself and it gets the job done. It's not that much more work to use that plugin than it would be to turn on a flag in ts-loader. All TypeScript errors are still printed without any changes to ts-loader. And when webpack2 hits the problem just goes away.
If this seems reasonable I'll add some documentation pointing people to this solution.
23 remaining items
gabro commentedon Jul 10, 2017
Hey @johnnyreilly is this issue still actual for modern versions of TypeScript?
I tried to use the
--noEmitOnErroroption of tsc (2.3+) and it appears to exit with code 1 and show meaningful errors.johnnyreilly commentedon Jul 10, 2017
I haven't tested lately and so I'm not sure.... Perhaps it's changed?
gabro commentedon Jul 10, 2017
It seems like an option, this was discussed more than a year ago.
What would be a quick way of testing it? Despite the readme, I've been recently surprised by this and accidentally deployed a broken bundle (in dev, thankfully)
johnnyreilly commentedon Jul 10, 2017
I've just noticed that you said:
You probably don't want to use this as it massively slows down compilation (can't emit until there are no errors at all)
My guess is you still need to use the fail plugin to fail the build. I still am...
gabro commentedon Jul 10, 2017
You're talking about incremental builds, right?
johnnyreilly commentedon Jul 10, 2017
No - production builds. Errors show up just fine in incremental
gabro commentedon Jul 10, 2017
Then I'm not sure I follow. Can you elaborate on how not emitting on errors slows down the build?
johnnyreilly commentedon Jul 10, 2017
Sorry - I had my wires crossed there. Here's my workflow:
What are you trying to do?
gabro commentedon Jul 10, 2017
Same setup. However I initially missed the fail plugin note on the readme and the CI deployed a broken bundle that didn't make the build fail.
I read this thread trying to understand why
ts-loaderdoesn't propagate TS errors to webpack, and I stumbled upon the issue about--noEmitErrornot providing useful messages.That doesn't seem to be the case with recent versions of TS.
I couldn't quite understand if there's other reasons of why errors are not propagated.
johnnyreilly commentedon Jul 10, 2017
Well if you have the fail plugin in place now then you should be good. I can't actually remember anymore the details of why I'm afraid.... @jbrantly may be able to advise.
gabro commentedon Jul 10, 2017
Yes, my CI is happy now.
However, I suspect I'm not and I won't be the only one being bitten by this.
Having the loader to propagate the errors to webpack is a reasonable expectation to have, so I'd like to understand what is the blocking issue.
johnnyreilly commentedon Jul 10, 2017
I think this is more of a webpack rather than a ts-loader issue. I agree it's a reasonable expectation to have. There's more context here: webpack/webpack#708
gabro commentedon Jul 10, 2017
Ah I see, thanks for the pointer.
Allow webpack 2 and 3 as peerDependencies
Lazarencjusz commentedon Feb 16, 2018
Unfortunately, in my case, when I want to use
thread-loaderorhappypackthewebpack-fail-pluginnot works (even I usenew ForkTsCheckerWebpackPlugin({ checkSyntacticErrors: true })plugin).