Do not create JavaScript files on errors

[kersam-bl]

It seems that the TypeScript compiler still produces JavaScript output when the .ts files contains errors:

function testFunc(x: string) {
}
testFunc(1);

Compiling this file gives me an error message:
E:/tmp/typescripttest/Errors.ts(3,1): error TS2082: Supplied parameters do not match any signature of call target:
Could not apply type 'string' to argument 1 which is of type 'number'.
E:/tmp/typescripttest/Errors.ts(3,1): error TS2087: Could not select overload for 'call' expression.

But nevertheless a .js is created.

This seems odd to me. If a compiler reports an error, I do not expect it to create an output file and do as if the compilation would succeed. So the hint which tsc is giving me here is more of a type of a warning: There is something wrong, but the compiler still tries to continue.

Why is this important?
People tend to "ignore" the errors if they are not fatal.
Additionally, this heavily confuses our CI server, since the error just "disappears" on the next build (we do not recompile the tsc if they are older than the resulting JavaScript).

[RyanCavanaugh]

We definitely want the behavior that the compiler can emit in the presence of type errors. This is a key scenario for migrating existing JavaScript -- you rename some .js file to .ts, get some type errors, but want to keep getting compilation of it while you refactor it to remove the type errors. They are 'warnings' in that sense; we cannot guarantee that your program does not work just because it has type errors.

That said, we recognize that this isn't always the behavior you want. Incremental builds get messed up by this on a fairly regular basis. We need something to address this scenario.

The most straightforward thing would be a command line flag (--doNotEmitOnErrors ? Could use a better name) that disables emit if we see type errors, same as how we don't emit if there are parse errors.

[danquirk]

The compiler error code does now reflect the various possible outcomes of the compilation (ex EmitReturnStatus.JSGeneratedWithSemanticErrors) so it should be possible for tools like grunt-ts to give you some ability to configure your preferred behavior for cases like this (where what you want here is essentially 'warnings as errors').

[DickvdBrink]

This one is fixed and can be closed right?

[RyanCavanaugh]

Yep. Documenting that we merged this in with the name noEmitOnError