tsc reports error that LS does not

[amcasey]

TypeScript Version: 3.9.7 & nightly

Search Terms: diagnostics

Steps

1. Clone https://github.com/amcasey/node-zwave-js
2. Check out Repro
3. npm install --ignore-scripts
4. lerna run build
5. Navigate to packages/zwave-js/src/lib/driver/SendThreadMachine.ts line 359
6. tsc -b -f packages/zwave-js/tsconfig.build.json

Expected behavior: Editor and tsc show the same errors around lines 359 and 368.

Actual behavior: Editor does not show errors.

Notes:

• I believe the LocalFix branch is a sensible way to resolve the errors. Locally, it only build with nightly - not with 3.9.7.
• I made a reduced version of the project to investigate perf, but it doesn't exhibit this issue.
• Technically, the LS uses tsconfig.json, rather than tsconfig.build.json but they're essentially the same and rejiggering the names to make them use the same tsconfig doesn't affect the behavior.

[amcasey]

Hat tip to @AlCalzone for the report.

[weswigham]

One word: Variance

This has taken a long time to chase down, as the chain of events occurring to cause the difference between the two clients is quite long; but what it comes down to is file check order affecting the order of variance calculations, which in turn end up affecting relationship comparison results. On the command line, when we try to find the variance for the first type parameter of SendAction, we need to lookup the variance for ActionFunction (which gets marked as Unreliable for using an optional mapped type over its parameter), which in turn looks at ActionMeta, which in turn looks at State, which in turn looks at StateNodeConfig, which in turn looks at InvokeConfig, which in turn looks at TransitionConfig, which in turn looks at AssignAction, which in turn looks at Required, which taints it as Unmeasurable all the way back up that chain and forces structural comparisons. When we then go to lookup the variance of the second type argument of SendAction, we encounter a cached result for the ActionFunction comparison's variance (which failed, and recorded an Unreliable marker), which we then propagate into the second type parameter's variance. This saved result causes it to be marked as neither co- nor contravariant in the second parameter, and is instead an Unreliable Invariant. This later causes us to try to assert invariance, fail, then perform a structural fallback (in just the covariant direction) which also fails, yielding a command line error.

Now in the language service, things go down differently. Ultimately the LS sees SendAction as being bivariant in its first two type parameters, rather than Unreliable/Unmeasurable and fails to report an error. I'm still looking into where, exactly the LS's variance calculation goes off the rails and what I can do to keep it synced up, but figured I should post an update.

[amcasey]

@weswigham if, along the way, you happen to notice a way to short-circuit some of these variance checks (probably by updating xstate), it seems like it would be a big perf win.