Skip to content

Design Meeting Notes, 3/29/2023 #53594

Closed
Closed
@DanielRosenwasser

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions