Repository navigation
Stale errors in tsbuildinfo file #42769
Description
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 --watchin 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.
Activity
sheetalkamat commentedon Mar 2, 2021
Please provide concrete repro steps with source code and changes that need to be followed step by step rather than just describing the issue. Without steps its hard to understand whats going on and whats expected.
dko-slapdash commentedon Mar 2, 2021
Sheetal Nandi (@sheetalkamat) That’s the problem, I can’t provide any repro steps, the effect is extremely unstable. Maybe you could provide some hints/guesses at least, how does the described behavior look like, knowing how it works internally?
6 remaining items
adrienharnay commentedon Apr 1, 2022
Hello Sheetal Nandi (@sheetalkamat) , I believe the problem I am facing today is the same as this issue, and I have a very simple reproduction for it: https://github.com/adrienharnay/typescript-buildinfo-bug-repro
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
If we are updating dts of any of the file and it affects global scope…
Build improvements (#48784)