Design Meeting Notes, 1/27/2023

[DanielRosenwasser]

@overload Not Checking for Compatibility in JSDoc

#52367

• In TS, we ensure the implementation is compatible with every overload.
• Now in JS with @overload, we don't.
• "It's a bug"
• Any time checked JSDoc and TypeScript have diverged, we've been sorry.
• There's likely a common issue where the implementation gets the type any without anyone knowing.
• We made @overload, we have say in how it works.
• Conclusion: fix it to be more compatible with TypeScript's overloads.

Unexposed APIs in typescript-eslint

https://github.com/typescript-eslint/typescript-eslint/blob/09c04fb0d5a5dee0dc266abb2e21aa9a1c489712/packages/type-utils/typings/typescript.d.ts

• ESLint augmented our public API to access a few /** @internal */ functions, but these are no longer actually available. (?)
• Think we will probably regret exposing getTypeOfPropertyOfType
• isArrayType, isTupleType, isTypeOfPropertyOfType, intrinsicName
• isArrayType only tells if you're an instantiation of Array or ReadonlyArray
  • Doesn't return true for subtypes of Array.
  • Feels a little...well, are you using it for non-structural checks?
  • Also need to have a built-in Array type present. Maybe need to document that.
• isTypeOfPropertyOfType
  • Can you emulate this with getSymbol... and getTypeOfSymbol?
    • We don't export that one either!
  • We export getTypeOfSymbolAtLocation
    • Hard to explain what that even does. It just works well enough for language service scenarios.
  • We use this for known symbol tables, we know you have to resolve constraints of generics.
    • Index signatures, intersections, ...
  • We would prefer to expose getTypeOfSymbol.
    • Public API functions take parsed AST nodes with parent pointers.
      • But this function doesn't take a node anyway.
    • This one is frequently requested.
    • Wacky that getDeclaredTypeOfSymbol but not getTypeOfSymbol is exposed.
  • If exported on 5.0, it would still work in 4.9.
• Seems like we want to export isArrayType, isTupleType, getTypeOfSymbol with lots of docs.
• Related: Proposal: Type Relationship API #9879

Difficulties With Thorough Excess Property and Weak Type Checks

#52392

• We try to perform excess property checks and weak type checks.
• As we descend into intersection types on the target type, we have to stop these checks due to false positives.
• To get around that, we do a second pass of these checks using the view of intersections as a "whole object".
• Then started tracking more state,
• We found a more general fix, but comparison on types for Vue 3 start going off the rails.
  • Becomes "excessively deep" to check.
  • Could think about composite recursion IDs to solve this.
• A fix where we only go 2 levels deep on excess property checks makes Vue 3 take twice as long to check.
• Could recur only for non-new instantiations - similar to exceptions for relating deeply nested types.
  • Unclear how you thread that in here.
• Is weak checking useful beyond a certain depth?
• All of this stuff is best-effort anyway.
  • Is it? Want it to be consistent.