Project-references type check with --noEmit fails without built files

[valerybugakov]

TypeScript Version: ^4.0.2

Search Terms: "has not been built from source file", "project-references", "typecheck without emit"

Description

In monorepo with project-references it's not possible to use tsc for type check only without emitting files.
Whereas calling tsc -b works without any issues. But there's no point in emitting files if we only need to perform type check of all related modules.

It seems that is should be possible because of: #32028

Expected behavior:

tsc with --noEmit builds all referenced projects without emitting anything:

tsc --noEmit -p ./zoo

Found 0 errors.

Actual behavior:

It fails because no built files are found for referenced projects:

tsc --noEmit -p ./zoo

zoo/zoo.ts:1:32 - error TS6305: Output file '/Users/val/Desktop/patch/project-references-demo/lib/core/index.d.ts' has not been built from source file '/Users/val/Desktop/patch/project-references-demo/core/index.ts'.

> import { makeRandomName } from "@p/core";

Playground Link:

repro repo

git clone https://github.com/valerybugakov/project-references-demo

cd ./project-references-demo
npm i
npm run typecheck

Related Issues:
#25613
#25600
#30661 (comment)

[RyanCavanaugh]

A .d.ts can be subtly different from the .ts that produced it, so you might not get identical results between a "virtual" build like this and a proper one, so enabling this is a dangerous thing to do. We could produce the .d.ts files in-memory in a serial build, but that's just build mode, and you're not invoking build mode so we can't legally go and inspect the referenced project. I'm not sure what we could do here; this was one of the listed caveats of project references from the get-go.

[valerybugakov]

@RyanCavanaugh Thanks for the response. This functionality looks like what I want to achieve using --noEmit flag from the CLI. It doesn't use .d.ts files and relies on "virtual" build to provide better DX with type-checking by inspecting source files of the referenced projects.

If it's true, it means that the mechanism is already in place. It would be great to expose some flags for developers to use it. Please correct me if I confuse two unrelated features. Maybe @sheetalkamat could suggest something regarding use of this functionality via CLI.

[RyanCavanaugh]

That PR is implemented by presenting the type checker with a virtual file system that builds .d.ts files on the fly; we can't enable it with a flag from tsc because it uses code specific to the language service process.

[taylorkline]

@valerybugakov Did you ever find a way to solve the problem you've described here?

[valerybugakov]

@taylorkline, not the root cause. We partially solved the performance issue in our project by caching type check commands per Typescript project with nx.

[scottwillmoore]

I think this issue should be reconsidered, and opened again.

It appears that not only do we get TS6305 errors, any files in project references do not appear to be type checked. I could be wrong, and I will create a reproduction in the future.

Project references are used in the Vite template for React and TypeScript which is very popular.

Any execution of tsc to check the types of a project in these cases would dangerous, as while Visual Studio Code will check the types a give a false sense of safety any CI/CD or tool such as Vitest will silently fail.

In addition, it is not efficient to run tsc --build, where many of these build with their own bunder.

EDIT: Here is a reproduction of this issue which I created for the Vitest team.

[neongreen]

That PR is implemented by presenting the type checker with a virtual file system that builds .d.ts files on the fly; we can't enable it with a flag from tsc because it uses code specific to the language service process.

We could produce the .d.ts files in-memory in a serial build, but that's just build mode, and you're not invoking build mode so we can't legally go and inspect the referenced project.

I'm confused — so is this a technical limitation (as the first quote implies), or a design/correctness limitation?

[ValentinGurkov]

I hope this topic gets revisited in the future. I just ran into this when I explored the idea of using project references to speed up type checking (via --noEmit). I have also opted for caching results via nx for the time being.

[ValeryLosik]

The thing is that project references put on the table some unique functionality like project boundaries, which can be extra useful in monorepo's workflow,however, it currently overlooks its potential due to the necessity of building files, leading to a performance degradation when compared to the --noEmit check.

In the realm of modern monorepo development, there's a shift towards employing rapid compilers like SWC and esbuild with extracting type checking into a separate task. In such approaches, emitting any files through TypeScript (tsc) becomes unnecessary, further enhancing overall efficiency. I would really like to see someday this feature in your roadmap.

[natew]

Run into this many times, I believe it should be fixed. There should be no reason to need to emit declaration files if you are just trying to type check and have noEmit set, and the errors are quite confusing.