Currently, we do not respect project references - the TS compiler APIs we use do not respect them, and we try to avoid doing tsconfig parsing directly ourselves.

This means that when two projects depended on one-another via project references, we create a program for project A, causing TS to load the .ts files for project A, and .d.ts files for project B. Then we create a program for project B, causing TS to load the .ts files for project B.

This obviously wastes time and memory on duplicated work (the .d.ts files) (#1192), and makes it harder to work on and lint two separate but referenced projects simultaneously, as you have to rebuild one to lint the other (#1973).

We currently do not have a good solution for this right now because the way projects work in TS isn't exposed to us in the APIs that we use. We'll have to build something - though what that is exactly we don't have a clear picture of.

Note that the way we work is different to TS. TS will build and check one project at a time when you run the CLI, whereas we will "build" every single project required to lint your codebase - meaning we are subject to different constrains compared to TS.
Likely there would need to be work done within TS itself so that it can deduplicate and manage things for us.

There are really two ways we can go about this:

1. treat project references as implicit and automatic parserOptions.project entries.
2. work with TS to deduplicate effort by sharing work when project references exist.