Don't stop on first Typescript error

[cmlenz]

It seems that tsify stops the browserify build on the first "error" reported by the Typescript compiler. I think it should output the error message but still continue, just like Typescript itself does. Am I missing something?

Can you share, as a documentation example, the handler you have and how its plugged in, for those of us who wish to have the same behavior, which is great for development (default one -- no-pass on any error -- is great for a production built).

[smrq]

I assume you mean you want output when there is a typing error? (On a syntax error, output cannot continue; currently, typing errors are just handled the same way.)

Sounds reasonable. I'll definitely put it behind a flag, though.

[cmlenz]

Yeah, typing error is what I meant.

I was surprised by this behavior of tsify as the TypeScript compiler itself does not behave this way, and this is advertised as a feature of TypeScript, for example in the tutorial:

Notice that although there were errors, the greeter.js file is still created. You can use TypeScript even if there are errors in your code. But in this case, TypeScript is warning that your code will likely not run as expected.

I would personally expect any frontend to the TypeScript compiler to follow this behavior.

An additional problem with stopping on the first typing error is that potentially other errors are not displayed until the first one is fixed, which is annoying during development.

[smrq]

All errors should be displayed; all of the type checking for the entire input is done in a single step. If you can whip up a simple example where errors cause others to be hidden, then that might be helpful for me.

You do make a compelling argument about what the default behavior should be. I'll strongly consider it.

[smrq]

Okay, the default behavior has been changed as of 0.10.0. Please try it out and see if it works for you!

(As soon as Travis CI pushes it to npm, that is.)

[smrq]

I'm having some trouble getting Travis to run the updated tests; I think the code is fine, though. Should be done soonish.

[smrq]

Released as 0.10.0. 🎉

[cmlenz]

Thanks @smrq !

Unfortunately it does not work for me. I'm probably doing something stupid. I've put up a test repo to demonstrate the problems I'm seeing:

https://github.com/cmlenz/tsify-test

This also shows how only one error is ever displayed, plus an issue where the message is printed as [object Object]. It would be very much appreciated if you could try it out.

My system information just in case:

> node --version
v0.12.2
> npm --version
2.7.5
> uname -mprsv
Darwin 14.4.0 Darwin Kernel Version 14.4.0: Sun Apr 19 20:30:19 PDT 2015; root:xnu-2782.30.2~2/RELEASE_X86_64 x86_64 i386

[cmlenz]

For what it's worth, I get the same results by skipping the Gulp build and directly executing browserify from the command line:

> > ./node_modules/.bin/browserify --debug src/index.ts -p [ tsify --target ES5 ]
TS2322: src/test.ts(6,12): TS2322: [object Object]

[smrq]

Thanks for the repro, I'll take a look as soon as possible

[smrq]

Figured out the [object Object] issue, I wasn't properly handling formatting of nested error messages. Still looking into why the other errors aren't showing up. Good test repo!

[smrq]

Ah, this one is an issue with the gulpfile. You have to handle errors thrown from Browserify or the whole thing will halt:

return b.bundle()
    .on('error', function (error) { console.error(error.toString()); })
    .pipe(source('test.js'))
    .pipe(gulp.dest('./dist'));

On the command line, since there isn't a way (that I know of) to catch those errors, you're out of luck. This appears to be a limitation of Browserify itself; for example, try compiling this with Gulp vs. on the command line, without tsify:

var qwer = require('qwer');
var asdf = require('asdf');
var zxcv = require('zxcv');

The gulpfile will report three 'Cannot find module' errors; the command line will report only one.

[cmlenz]

Ah, thanks for the tip (and the [object Object] fix). I've updated my test repo and it now works nicely with Gulp.

So Browserify doesn't provide a mechanism for plugins to report warnings rather than fatal errors?