Design Meeting Notes, 8/24/2022

[DanielRosenwasser]

Type Reference Directives in nodenext

#47444

• Usually TypeScript crawls through node_modules/@types and brings them into the program unless you use the types field.
• There is also a way to bring something in via code with /// <reference types="some-package" />
• node16 resolution can support both import and require.
  • Current assumption is that we should resolve to whatever an import would do in that file.
  • So a /// <reference types"..." /> does will go to import in ESM, require in CJS
• Okay, now what should happen from types a tsconfig?
  • Feels like we should refer to the type field in package.json.
  • What if you have one tsconfig for several package.jsons?
• Aren't these just useful for globals anyway?
  • Pretty much - node, mocha, react-native, webpack, etc.
  • Ugh.
• Only Node.js cares about .mts and .cts - bundlers just go to the exports.
  • So under a bundler-oriented mode, maybe always follow import?
• If global files are global, why does it matter what kind of resolution they under-went?
  • Loading identical files from a package.
• Another take - always do both.
  • But then you have identical declarations.
  • Hopefully they are the same! One position is that it's an accident waiting to happen.
• When we talk about types in tsconfig, we're really talking about node_modules/@types, which almost always corresponds to DefinitelyTyped.

  • Meaning we could say "it's always import, we'll make sure DefinitelyTyped guarantees identical types"

  • really talking about node_modules/@types

    Not quite true - this is only true for unspecified types array. A specified entry in types will do a resolution into node_modules.

    • 😫
    • 😫
    • 😫
    • 😫
• "I hate modules"
  • "I hate types"
• By the way, if you do /// <reference types="foo" />, we'll go into node_modules and grab foo.ts
  • Not even node_modules/@types/foo.ts
  • "Stop it."
  • Remove this behavior.

Substitution Type Optimizations

#50290

• We have the notion of a "substitution type" in conditional types.
  • Effectively a way to encode implicit bounds in the true branch of a conditional type.
  • When using the original type variable in question, create an intersection between the original type and the bound.
  • Not desirable to just rewrite these as intersections - you want the language/language service to preserve information about how it came to be.
    • Quick info etc. should preserve display as the original type variable.
• We started caching 16M relations in a repro in 4.8.
  • Triggered by a signature in @types/babel__traverse.
• Started forming a cartesian product on some conditional types.
• Have the chance to remove some code where we don't preserve the substitution type upon instantiation.
  • Cheaper, but it broke vuejs/devtools
  • Why does it break? Because the substitution type stops an infinite type from going deeply recursively.
  • Hyrum's Law
• Okay, that's what broke devtools - what broke xstate?
  • We can't make sense of what xstate is inferring.
• We can still try to make more-conservative changes.

[fatcerberus]

• "I hate modules"
  • "I hate types"

🤣