Disable noEmitOnError

[jakebailey]

After #58854, build mode proceeds even if there were errors. However, in our codebase we use noEmitOnError.

If I stick a random type error in src/compiler/types.ts, then run the build, I end up with 17 thousand errors:

src/typingsInstaller/nodeTypingsInstaller.ts:177:22 - error TS2339: Property 'log' does not exist on type 'NodeTypingsInstaller'.

177                 this.log.writeLine(`    Succeeded. stdout:${indent(sys.newLine, stdout)}`);
                         ~~~

src/typingsInstaller/nodeTypingsInstaller.ts:183:18 - error TS2339: Property 'log' does not exist on type 'NodeTypingsInstaller'.

183             this.log.writeLine(`    Failed. stdout:${indent(sys.newLine, stdout)}${sys.newLine}    stderr:${indent(sys.newLine, stderr)}`);
                     ~~~


Found 17418 errors.

This really breaks the self check in CI (like https://github.com/microsoft/TypeScript/actions/runs/9868392724/job/27250345885?pr=59217).

Disable the flag in our codebase, netting:

$ node ./built/local/tsc.js -b ./src
src/compiler/types.ts:10277:14 - error TS2322: Type 'string' is not assignable to type 'number'.

10277 export const oops: number = "string";
                   ~~~~

Found 1 error.

This does make me wonder if noEmitOnError is now just a general hazard when using build mode. Maybe this flag should really enable the old behavior? #58854 (comment)

Or, detect when a dependency has noEmitOnError, had an error, then also refuse to build?

[jakebailey]

@sheetalkamat What do you think of modifying tsc -b to refuse to build if a dependent project had noEmitOnError set and didn't emit? It seems like otherwise, you'll always end up with a very large set of errors...

For people who don't care about the emitted files, removing this flag is still a good idea IMO since you'll get everything anyway, so this PR itself seems like what we want (so I'm going to merge).

[sheetalkamat]

It isnt that simple and i had thought about this but i think we should try it out and seek more feedback.
If depends on whether clean build was done or not. because if clean build was done and then introduced error, the rest of the projects most likely wont build at all since d.ts wont change.