Design Meeting Notes, 8/3/2022

[DanielRosenwasser]

Granular Resolutions

https://github.com/microsoft/TypeScript/issues/50152

• Almost everyone using modules these days is using a resolution format called node.
  • Even if you're not using Node.js - for example, bundlers such as Webpack and the like.
• Eventually, Node.js added new resolution rules.
  • For example, the exports map.
  • Webpack also supports features like these.
• When we added the node16, people thought "oh cool, now I can use the exports map".
  • Yes, with a bunch of new restrictions.
    • For example, explicit file extensions (e.g. everything must end in .js, .mjs, or .cts).
      • Arguably not the worst, but definitely confusing if you're authoring in .ts, .mts, or .cts.
  • But bundlers and the like don't adhere to those restrictions.
• Devs using bundlers really didn't like that restriction!
• What if we had something like node with some of the overlays that bundlers and the like support.
  • node mode accurately models a subset of them, and Node.js versions older than 12.
• Can't support EVERY resolution mode out there. Maybe we can start with subsets and provide means to enable common features that are layered on top of them.
  • conventional/hybrid(?) - bundler modes
  • node16 - you use Node.js
  • minimal - something like what bundlers use, maybe custom/internal build
• The logic that users don't like the Node.js restrictions so we should provide a mode that lets them take full advantage of their bundlers - is that good?
  • Is this just something people have to get over?
  • Zero bundlers enforce the same rules as Node.js.
  • That means that the community has sort of spoken.
  • Plus, people thinking "I'll write .ts" for my extension" is another big confusion point.
  • Look at what docs and boilerplates do today.
• Could conventional have features layered on top to build up the node16 mode?
• Have to think about the split between library authors and app developers.
  • Former probably want to use node16, latter should use conventional.
  • But there's nuance - not every library on npm is intended to be used on Node.js (e.g. web, React Native, etc.)

satisfies Operator

https://github.com/microsoft/TypeScript/issues/47920

• Contextually types an operand, makes sure the operand is assignable to the type.
  • Don't want to lose the type of a literal, but want to make sure it conforms to some shape.
• Some nuance.
  • Thought
• Was some concern around how satisfies plays with types as comments/type annotations proposal.
  • Isn't at conflict, per se - didn't want to give the appearance of "unstable" syntax.
  • We shouldn't stop TypeScript innovation based on it - type annotations can incorporate as we learn as well.
  • .ts can always be a superset of JS with types anyway.
• So binary operator? No alternative?
  • as ~ T
  • as PLEasE
  • as satisfies
    • as satisfied by
    • <satisfies Foo>expr?
  • Type operator that can only be used in as assertions? (e.g. as (satisfies Foo))
• The infix no-line-terminator space is the only place we are willing to trample, and we do it mindfully. In 27 years since JS has existed, nobody has needed satisfies for non-type purposes. There is a point where waiting speculatively in case that happens means you're just not shipping anything at all.
• Drive for early in 4.9 release cycle, get feedback.

[fatcerberus]

• Some nuance.
  • Thought

🤣

[DanielRosenwasser]

That must have been a typo but I like it. It stays.

[DanielRosenwasser]

I think that was meant to be the description of why we went back and forth on what satisfies should do.