Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
Description
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 projectA
, causing TS to load the.ts
files for projectA
, and.d.ts
files for projectB
. Then we create a program for projectB
, causing TS to load the.ts
files for projectB
.
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:
- treat project references as implicit and automatic
parserOptions.project
entries. - work with TS to deduplicate effort by sharing work when project references exist.