Some people are getting some value out of it but I'd guess that the improvements released in v7.9.0 and soon to release in TS5.5 are going to fix some OOMs.

There are footguns with it as well so yeah I'm happy if we remove it.

The reason it never progressed is because essentially TS would only parse a subset of files from another tsconfig. So it meant that in many cases perf/memory was worse!

A .d.ts file is light - only contains the exported decls and their types - but a .ts file is heavy as it contains all the imementations AND pulls in more of the dep graph than necessary.

If project A references project B then when we got the program for A then TS would parse and typecheck a subset of B's .ts files. But unless that "subset" somehow was actually the entirety of B, then when we inevitably parsed an out-of-subset part of B, we would need to get the program for B - meaning we'd re-parse and re-typecheck that subset all over again.

OTOH with .d.ts files - because you're only parsing a file's exported signature - it's always lightweight and includes the minimum types to define that signature. So the file is light and the graph is light. There's not much type-check work to do because there aren't implementations to check.

Also imagine if there are some node modules used in implementations for B (but not A) - and those module's types aren't used in the exported signatures. With .ts files we'd need to typecheck the types for that node module twice (once for A then once for B) - but with .d.ts files we'd only need to do once (once for B).

Finally imagine a highly interdependent project. Eg imagine if you have C, D, and E which all also depend on B. Now you have 4 copies of the subgraph of B.

Essentially it was a dead-end. It kind-of let us share types between programs in specific usecases but in reality it was worse.
We really want to say "this program uses types from this program" to have two isolated but shared things - but TS doesn't support that.

#9104 was merged into the v8 branch. ✅