Design Meeting Notes, 3/29/2023

[DanielRosenwasser]

External Tools Operating Over Multiple Projects

evanw/esbuild#3019

• What should people expect out of tools supporting TypeScript like esbuild?
• esbuild will always look for the closest tsconfig.json
• Feels like part of it comes down to thinking about projects vs. code-split outputs maybe?
• Maybe tools never look at TypeScript's target etc.?
  • Less easy to say with the JSX factory.
• useDefineForClassFields?
  • swc switches it on.
  • Maybe esbuild does now too.
• TypeScript's config is often supposed to be a declarative description of the end runtime.
• We need to come back to this after reading it more deeply.

Implicit Returns with Explicit Return Type Annotations

#53559

// Was error, now okay. Should it be an error with `noImplicitReturns`?
let q1 = (): undefined {};

// Was error, now okay. Should it be an error with `noImplicitReturns`?
let q2 = (): string | undefined {};

// Differences with contextual typing?
// Still an error, inconsistent with the above.
let q3 = ()

// No contextual type, will continue to error.
let q4 = () => {}; // inferred as () => void;
let q5: () => undefined = q4;

// Was error (with or without noImplicitReturns), now okay.
// Should it still be an error
let q6 = (): unknown => {};

// Was 'Not all code paths return a value' with noImplicitReturns.
// Now it isn't.
let q7 = (b: boolean): unknown => {
    if (b) return 42;
}

• Took a PR to say "if the return type includes undefined, we allow implicit returns".
• Thought these were caught by noImplicitReturns
• Returning undefined implicitly
• 3 states
  • I can never return undefined - actually can.
  • I always return undefined - implict return is probably okay (at least in some mode?)
  • I sometimes return undefined
  • (void?)
• Does noImplicitReturns really mean "no implicit returns every unless any and void"
  • Or bare undefined?
    • Fine. Who the heck does that unless they know what they're doing?
  • What about number | undefined?
• any and unknown always swallow up other types.
  • What about number | void?
    • Usually people mean unknown?
    • Maybe number | undefined?
• Contextual types?
  • Same issues as empty arrays though. Concerns with capture and constraints affecting the inferences.
  • Would like to
• Explicit undefined?
  • Treat that like plain undefined.
• Empty body special case for unknown?
  • No.

Divergent Getters and Setters

#53417

• Today, getters and setters have to be related.
  • But the reality of the DOM APIs in JavaScript is that they don't need to be.
• We've said foo.bar = foo.bar should always be allowed.
  • But again, document.body.style = document.body.style makes this not true.
• Are there assumptions that we make about the getter based on the setter and vice-versa.
• Indexed access types?
  • T[keyof T]?
  • Read types or write types?
  • We always pick the read types.
• Probably should have a lint rule to opt back into the old behavior.
  • Could say "only in .d.ts files?"
  • Would get funky.
  • DOM is one example, but real-world TypeScript code.
  • Immer, GraphQL ORMs,
• Variance?
  • Does a generic only in a set parameter make something contravariant?
  • We never look at the write-type, so the type parameter's variance would be independent.

[fatcerberus]

Are there assumptions that we make about the getter based on the setter and vice-versa

I didn’t see this mentioned in the notes and I’m not even sure it’s relevant here but: set prop(value) {} -> type of value is inferred from getter return value.

[DanielRosenwasser]

Yup - and vice versa. When the types diverge, you need an explicit annotation.