Design Meeting Notes, 2024-03-05 #57655

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

• /// <references> in isolatedDeclarations

  • Reference synthesis/ellision is confusing and impossible for ID
  • Goals
    • Stop synthesizing, ever
    • Preserve, always(ish?)
  • How breaky is this?
    • Many people synthesize react types directives, seemingly for not much reason since these also import react
    • Also many refs to node
    • Some to jest
    • Very few seemed actually necessary in any way
    • There was one interesting one in the top 200
      • vercel/swr/src/core/index.ts
      • Input file writes import 'client-only';
      • This causes an env.d.ts reference path to be synthesized above it
        • Because it's an ambient module that didn't load via resolution
      • This would (in theory) cause a resolution failure
      • Except! resolution failures are silenced if no identifiers get bound from that import
      • This package clearly has some declaration bundler magic going on
    • So still a concern in theory, just not in practice from the top200
    • Footgunish since you can't detect these potential problems at build-time
      • Matching/subsetting config is an existing problem, not novel
      • This is a subtle misconfiguration, if it's a misconfig at all
      • Figuring out if it's even possible to downstream an output is difficult, let alone what the mandatory config option(s) are
      • Emit as-is, preserve always, do not synthesize
      • Depending on a transitive dependency is wrong!
  • 5.5 or 6.0?
    • Enable this behavior in isolatedDeclarations only?
    • Or introduce --verbatimReferenceSyntax ?
    • Is this actually liable to break anyone in a real way?
      • Feels like no (for synthesis)
    • The reverse (preservation) seems riskier
      • Could pull in files that are missing, or are conflicting globals
    • /// <reference path="foo" />
    • /// <reference path="foo" preserve />
      • We were smart and can parse this in old versions
    • 5.5
    • Let's run a PR to check for re-print of directives just to sanity check

• Propagation outer type parameters of single-signature types Propagate outer type parameters of single signature types #57403

  • nested generic function inference causes unbound type parameter leak #55467 has a type parameter leak
  • Repro depends on several factors
    • Requires trafficing through outer type parameters on the function expression
    • Instantiation of these gets deferred
    • Deferred too long (forever)
    • Needs to be instantiated with the type parameters of the outer call
    • PR fixes this to capture the outer type parameters correctly
    • PR fixes another problem where we captured a candidate of the form A = [A[0]], which would tautologically arrive to the constraint (unknown) and spoil the inference
      • Because the tuple type and argument form aren't instantiations of the same type
    • How did this even work in the first place? i.e. What's special about this case?
      • Read the PR notes; too complex to fit in this margin