Stale errors in tsbuildinfo file

[dko-slapdash]

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.

1. I opened client/dist/tsconfig.tsbuildinfo in a text error, and I see this error there.
2. 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.
3. 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?).
4. 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.

[sheetalkamat]

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]

@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?

[lukeapage]

We get something similiar. We cannot share the repo it happens in - its 800k lines of proprietary code. I delete the cache and then the error disappears. In our case its always generics. In case it helps this is the most recent case:

[ts:watch-frontend] <redacted>/selectors.ts:241:9 - error TS2769: No overload matches this call.
[ts:watch-frontend]   The last overload gave the following error.
[ts:watch-frontend]     Argument of type 'OutputParametricSelector<State, string, Dictionary<Instrument>, (res1: Dictionary<Instrument>, res2: Dictionary<
Instrument>, res3: any) => Dictionary<...>>' is not assignable to parameter of type 'ParametricSelector<unknown, unknown, InstrumentGroupItems | null | un
defined>[]'.
[ts:watch-frontend]       Type 'OutputParametricSelector<State, string, Dictionary<Instrument>, (res1: Dictionary<Instrument>, res2: Dictionary<Instrument
>, res3: any) => Dictionary<...>>' is missing the following properties from type 'ParametricSelector<unknown, unknown, InstrumentGroupItems | null | undef
ined>[]': pop, push, concat, join, and 28 more.
[ts:watch-frontend]
[ts:watch-frontend] 241         createGetInstrumentsData(),
[ts:watch-frontend]             ~~~~~~~~~~~~~~~~~~~~~~~~~~
[ts:watch-frontend]
[ts:watch-frontend]   node_modules/reselect/lib/index.d.ts:960:17
[ts:watch-frontend]     960 export function createSelector<S, P, R, T>(
[ts:watch-frontend]                         ~~~~~~~~~~~~~~
[ts:watch-frontend]     The last overload is declared here.

Without giving you the whole source code, is there any way to help define what the issue is?

[adrienharnay]

Hello @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