It's gonna be a not well-structured bugreport unfortunately, since the effect is hard to reproduce. I hope it's already tracked somewhere (or maybe even addressed).
There is a monorepo with 2 project (say, shared/ and client/), and client/src/a.ts references a string union type T = "aa" | "bb" in shared/src/t.ts which is changed frequently. The two projects build independently, so basically client/a.ts references shared/dist/t.d.ts file (i.e. a.ts references *.d.ts in shared/).
Often times after adding a new alternative to T and using it in client/, when building client/, we see a compilation errors saying that this alternative is not in type T ("Argument of type T is not assignable ..."), although it's there, and shared/dist/t.d.ts is correct too.
- I opened client/dist/tsconfig.tsbuildinfo in a text error, and I see this error there.
- I manually edited this error in tsconfig.tsbuildinfo file (semanticDiagnosticsPerFile), and the output of
ttsc --watch in client/ changed accordingly - i.e. I proved that tsc reads this error from tsconfig.tsbuildinfo and skips compilation for some reason.
- shared/dist/t.d.ts is correct. I tried to
touch shared/dist/t.d.ts - no luck. I also tried to change its content manually (added a comment) - no luch too (which is weird: the content changed, so the checksum changed too; why didn't tsc notice that?).
- It looks like that if I remove the error objects from semanticDiagnosticsPerFile section of tsconfig.tsbuildinfo, the build succeeds.
I.e. it looks like while building client/, tsc for some reason ignores the checksums rechecking in tsconfig.tsbuildinfo and instead just throws the same error it threw before.
What resolves this error is following: if I rename shared/dist/t.d.ts.BAK, then rerun tsc --watch for client and see the new errors, then rename it back - then the error disappears.
Is it an issue in tsc somewhere? Or maybe there is a way to clean all the stale errors in tsbuildinfo file to make sure tsc --watch doesn't rely on them?
P.S.
skipLibCheck=true, composite=true (but shared/ is built independently, no references), incremental=true, declaration=true
Could you please provide some more details on how semanticDiagnosticsPerFile works and how does it recheck the files for changes? Because there is definitely a change in t.d.ts file, and this file is mentioned inside the list of files in semanticDiagnosticsPerFile, but despite of that change, tsc still throws the stale error.
It's gonna be a not well-structured bugreport unfortunately, since the effect is hard to reproduce. I hope it's already tracked somewhere (or maybe even addressed).
There is a monorepo with 2 project (say, shared/ and client/), and client/src/a.ts references a string union type
T = "aa" | "bb"in shared/src/t.ts which is changed frequently. The two projects build independently, so basically client/a.ts references shared/dist/t.d.ts file (i.e. a.ts references *.d.ts in shared/).Often times after adding a new alternative to T and using it in client/, when building client/, we see a compilation errors saying that this alternative is not in type T ("Argument of type T is not assignable ..."), although it's there, and shared/dist/t.d.ts is correct too.
ttsc --watchin client/ changed accordingly - i.e. I proved that tsc reads this error from tsconfig.tsbuildinfo and skips compilation for some reason.touch shared/dist/t.d.ts- no luck. I also tried to change its content manually (added a comment) - no luch too (which is weird: the content changed, so the checksum changed too; why didn't tsc notice that?).I.e. it looks like while building client/, tsc for some reason ignores the checksums rechecking in tsconfig.tsbuildinfo and instead just throws the same error it threw before.
What resolves this error is following: if I rename shared/dist/t.d.ts.BAK, then rerun tsc --watch for client and see the new errors, then rename it back - then the error disappears.
Is it an issue in tsc somewhere? Or maybe there is a way to clean all the stale errors in tsbuildinfo file to make sure tsc --watch doesn't rely on them?
P.S.
skipLibCheck=true, composite=true (but shared/ is built independently, no
references), incremental=true, declaration=trueCould you please provide some more details on how semanticDiagnosticsPerFile works and how does it recheck the files for changes? Because there is definitely a change in t.d.ts file, and this file is mentioned inside the list of files in semanticDiagnosticsPerFile, but despite of that change, tsc still throws the stale error.