Project References and noEmitOnError

Search Terms

project references
noEmitOnError
build flag

fast development feedback

babel/preset-typescript
babel/plugin-transform-typescript

Suggestion

Project with error in it should not be marked as up to date.

Build flag should respect noEmitOnError preference as set by user in .tsconfig

I understand that current works-as-expected is that the build flag sets this to true. This is a feature request with suggestions on how to change that design.

Per Typescript Handbook - Project References - Caveats

if one of your out-of-date dependencies had a new error, you’d only see it once because a subsequent build would skip building the now up-to-date project

Suggestion: Project with error in it should not be marked as up to date

• Can this assumption be changed?
• Maybe .tsbuildinfo file can be used to store this state?
• Incremental compilation works well with single projects and with watch flag: maybe the same mechanism for detecting up-to-date can be used for multiple project builds?

Use Cases

Fast development feedback. In my case, I'm running both tsc -wb and jest --watch side by side. I want my test cases to run even if my types aren't perfect.

Right now, I am forced to resolve ALL type errors before I can get any feedback. This makes it difficult to develop iteratively.

Moreover, what is not seen in this issue tracker here: A number of people are now running babel and typescript side by side. One of the reasons could very well be just this. There is no need to run babel for pure transpilation if typescript can emit with errors.

Examples

dev feedback; live test cases; live browser refresh; other use cases

Other people:
https://github.com/microsoft/TypeScript/issues/29851
https://github.com/microsoft/TypeScript/issues/25600#issuecomment-450644121
https://github.com/microsoft/TypeScript/issues/25600#issuecomment-473389927
https://github.com/microsoft/TypeScript/issues/25600#issuecomment-482865289

Workarounds

Meanwhile, we can do this:

• run tsc --watch directly in the referenced project directory
• // @ts-ignore OR // @ts-nocheck flags

Checklist

My suggestion meets these guidelines:

• [x ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [ x] This wouldn't change the runtime behavior of existing JavaScript code
• [ x] This could be implemented without emitting different JS based on the types of the expressions
• [ x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x ] This feature would agree with the rest of TypeScript's Design Goals.

Start by reading the Project References - Caveats section linked in the issue and the related issues 29851 and 25600. Define how project references, noEmitOnError, and .tsbuildinfo should interact, then verify that erroneous projects are not treated as up to date while preserving fast development feedback.