[heft] typescript warning should not ignore when `noEmitOnError` is set

[GongT]

Summary

When noEmitOnError is true, and some typescript error occur:

• heft build treated some error as warning
• but the compiler do not really emit/update any file
• heft exit with code 0 (success)

In my case (I'm using rush)

• this behavior cause rush continue to build next package
• unpredictable result 💥💥💥

Repro steps

Example repo: https://github.com/GongT/issues/tree/heft-typescript-warning

1. clone & npm install
2. heft --debug build

Details

Related code:

https://github.com/microsoft/rushstack/blob/main/apps/heft/src/plugins/TypeScriptPlugin/TypeScriptBuilder.ts#L579

https://github.com/microsoft/rushstack/blob/main/apps/heft/src/plugins/TypeScriptPlugin/TypeScriptBuilder.ts#L770-L795

Standard questions

Question	Answer
@rushstack/heft version?	0.46.1
Operating system?	Linux
Would you consider contributing a PR?	No
Node.js version (node -v)?	18.3.0

[GongT]

Not important issue. I will turn off noEmitOnError and use eslint.

[iclanton]

It sounds like the specific error that you're seeing is getting adjusted down to a warning by Heft, and so emit is happening and Heft isn't exiting with a nonzero exit code. Is that the issue you're facing?

Would adding more options for mapping diagnostic codes to error/warning behavior in config/typescript.json (as mentioned in this code comment) work for your scenario?

[GongT]

sorry for my poor english.

I think builder can just print an error when noEmitOnError is true (and refuse to run build at all)

Mapping codes is a great feature, but not help to this (maybe even worse!).
The issue is: typescript compiler think X is an error, so it will not write any file (noEmitOnError, as expect). But heft was configured to treate it not an error! This will confuse user and higher level tool. (eg. rush, will create an empty/stale cache)

this issue is so tiny, not fix is OK. (I report this just because I will save 1 hour if sombody report this before LOL)

[iclanton]

We're working on refactors to the way TypeScript is compiled in an upcoming version of Heft. Under that new model, transpilation will be separated out from typechecking. These downmapped errors would then be bubbled up during the typechecking step, which would then block the build, but still emit files allowing downstream projects to use them. In our design discussions, it seemed like the best of both worlds. Thoughts?