No output emitted even for correct files in Project References if one file has error

[dandv]

TypeScript Version: 3.9.2

Search Terms:
project references emit error force noEmitOnError

Code

tsconfig.json

{
  "files": [],
  "references": [
    { "path": "./project1" }
  ]
}

project1/tsconfig.json

{
  "noEmitOnError": false
}

project1/ok.ts

console.log('Hello world');

project1/fail.ts

const foo: string = 42;  // TS error
console.log(foo);

Expected behavior:
When I run tsc --build --force --verbose, I expect at least project1/ok.js to be output, because:

1. ok.ts compiles correctly
2. there are no dependencies mentioned in the Caveats section on Project References
3. I've specified "noEmitOnError": false explicitly in project1/tsconfig.json
4. I've passed the --force flag

Actual behavior:
Nothing is generated.

Reproduction repo:
https://github.com/dandv/ts-project-ref-bug

[RyanCavanaugh]

I'm not sure about this. We currently emit zero files on purpose, since:

• There might be errors not associated with any file, so if we emitted files that don't have errors, we could end up putting the project in the "up to date" state despite it having errors
• You'll have to recompile anyway, so...

Why do you want this to happen?

[sheetalkamat]

This is working as intended. tsc -build indirectly means --noEmitOnError. Having said that we not emit tsbuildinfo if there are errors so incremental builds should be speedy

[JoelEinbinder]

Why do you want this to happen?

For my project, typescript errors are generally not a big deal. Usually red squiggles mean something needs to be casted to the correct type. I want to be able to test my code before I fix all type errors, so I have noEmitOnError: false. Nothing about this changes for me when I move to multiple projects and --build. I still have squiggles and I want to run my code.

This is working as intended. tsc -build indirectly means --noEmitOnError. Having said that we not emit tsbuildinfo if there are errors so incremental builds should be speedy

Does tsbuildinfo contain the error messages? I think that would allow failing the build even if the project is in the up-to-date state.

[trusktr]

Why do you want this to happen?

We want to just run the plain JS to see if it works. Sometimes we want to treat type errors as warnings, especially useful when migrating code, or refactoring, so we can at least run and verify the app works too (it's just JS). Sometimes global pollution, etc.

Despite type errors, the code may work perfectly fine, and sometimes we want TS to be out of the way so we can show that neat prototype we just made (the person viewing the prototype doesn't need to know there are type errors).

Boss: can you show the prototype in the meeting?
Dev: Yeah, it'll be awesome.
Dev(thinking): Oh crap, @types/node globals and other global pollution, or something, getting in the way causing errors, I don't have time for this now. TypeScript won't let me build my code so I can just run it!! It's just JS anyways, come on!! Why is TS not letting me do what I need to do!!
Dev(later): Sorry boss, some issues with TypeScript...
Boss: 😭

Not a fun situation...

[sheetalkamat]

#32651 discusses tsc -b when there are errors