Repository: TypeScript
Issue: Project References and noEmitOnError
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

project references
noEmitOnError
build flag

fast development feedback

babel/preset-typescript
babel/plugin-transform-typescript


## Suggestion

<!-- A summary of what you'd like to see added or changed -->

**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](https://www.typescriptlang.org/docs/handbook/project-references.html#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.

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples

<!-- Show how this would be used and what the behavior would be -->

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](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).