Repository navigation
Inconsistent errors reported between tsc and VSCode #52813
Description
Bug Report
The basic problem looks like this:
- I run
tscdirectly from the command line and get Set A of errors. - VSCode instead shows Set B of errors which can be wildly different than Set A
- If I issue the TypeScript: Restart TS Server command to VSCode, I will then start to just see Set A errors in my IDE
- However... if I go and make a small change to a file I start only seeing Set B errors again.
Set B errors seem completely wrong since the tsc doesn't produce them. HOWEVER, a specfically unique error in Set B seems to be causing this weird behavior:
'Value' implicitly has type 'any' because it does not have a type annotation and is referenced directly
or indirectly in its own initializer.ts(7022)
If I solve this error with an explicit type assertion, the inconsistency goes away and I resume seeing Set A errors.
My project does rely on a deep set of types involving conditionals and generics. This seems to have something to do with causing this problem. I've provided a repository below with steps on how to reproduce. I would try to narrow the behavior down to a simpler project+repo but do not have the time at the moment.
🔎 Search Terms
inconsistency, inconsistent, errors, ts language server,
🕗 Version & Regression Information
This issue was tested and occurs in TypeScript 4.9 and the latest nightly build as of this writing (5.0.0-dev.20230216).
⏯ Playground Link
Unfortunately I'm unable to reproduce this with the TS Playground
Repo+Branch that reproduces the issue
- Navigate to
Stepper.tsline 77. See the TSDoc comment there for reproducibility steps. It can some times take a few file modifications to trigger the behavior. - I was able to reproduce the same issue using GitHub Codespaces.
💻 Code
See Repo above.
🙁 Actual behavior
- TypeScript errors reported by VSCode are inconsistent with the ones reported by running
tscvia the command line. - VSCode can be temporarily made consistent by restarting the TS Server.
- A single error seems to be causing TS+VSCode to act in this way.
🙂 Expected behavior
- TypeScript errors reported by VSCode should always match with the ones reported by running
tscvia the command line.
Activity
gabritto commentedon Feb 23, 2023
Hi Frank Weindel (@frank-weindel), I have been trying to reproduce this using the instructions you left, but so far I wasn't able to. If you're still able to repro this, could you repro it with logging enabled on tsserver, and post the tsserver logs here? That would help me investigate this issue. Thank you.
In case you don't already know how to do get a tsserver log:

(1) You can enable logging on vscode by going to your settings and looking for "Tsserver: log" setting, and setting it to "verbose".
(2) Once you have logging enabled, and you manage to reproduce the issue, you can then open the log by running the "TypeScript: Open TS Server log" command on vscode:

frank-weindel commentedon Feb 23, 2023
As requested!
Specifically what I did to reproduce was:
Stepper.tsin a tabProgressStepper.tsProgressStepper.tsStepper.tslights up with the errorgabritto commentedon Mar 3, 2023
I think the following program captures the essence of this issue:
You don't get the circularity error reported on the above program, but you do get the error if you swap the
FieldandValuedeclarations:Playground link
Essentially, what is happening is that, if we type check property
Fieldfirst, we succeed and we cache some types and variances, so that when we then type checkValue, we don't run into a circularity and everything works. If we start by type checkingValueinstead, we run into a circularity. So whether we get the circularity error or not depends on the order in which we check those properties.Translating that to the original reported issue, what happens is that, when we run the checker via
tsc, we type check fileStepper.tsand then we check fileProgressStepper.ts. In an editor context, we sometimes checkProgressStepper.tsand then we checkStepper.ts, and when that happens, the circularity error is reported.RyanCavanaugh commentedon Mar 3, 2023
Does adding variance annotation(s) to
Stepperfix the issue?gabritto commentedon Mar 3, 2023
Yes, computing variance for
Stepperis how we run into the circularity when type checkingValue.RyanCavanaugh commentedon Mar 3, 2023
Here's a variant repro I was trying out
checker: a circular generic type's variances no longer depend on wher…