Design Meeting Notes, 4/17/2020

[DanielRosenwasser]

Inference with Promise-Likes

#37615

Worked on a heuristic when inferring to T | PromseLike<T>

let a!: Promise<number>;
let b!: Promise<string>;
let c!: Promise<number> | Promise<string>;

Promise.resolve(a); // Promise<number>
Promise.resolve(b); // Promise<string>

// Previously: error
// Now: Promise<number | string>
Promise.resolve(c);

• In review for awaited, we realized that this sort of inference generalizes when the types are soundly covariant (i.e. covariant on )
  • But we don't track "sound covariance" right now.
  • Sounds like it's possible - could we start tracking it?
    • Could, don't have it there yet.
  • Could also do this for ReadonlyArray.
• Still need awaited for the recursive unwrapping.
• [[3 minute discussion on how awful JQuery's Promise type declaration is]]
• Conclusion: let's get some reviews and get this in for 4.0 🎉

Auto-Typed Instance Properties in JS

#37900

• In JavaScript files, we do a bunch of heuristics to figure out the types of properties on this.whatever within constructors and methods.
• We track all the this.whatever assignments within a class and consider them assignment declarations.
  • We union all these declaration types.
    • Works, but doesn't always work; but if a property is conditionally set, we really should say "this thing is possibly undefined.
    • Also causes circularity issues when you have something like this.foo = this.foo.slice(1); or this.foo = this.foo ** 2;
• With Control flow for constructor initialized properties #37920, we say that if a property is declared with an initializer in the constructor but no JSDoc type, it is a constructor declared property
  • In these cases, they're auto-typed and we use control flow analysis to figure out the type of each of these properties at the end of the constructor's scope.
  • Similar to what we do for let x; in --noImplicitAny.
  • Old heuristics are still around, but only when there's no assignment in the constructor.
• We also do things like tracking when you have an auto-typed array - same stuff for let x = [] in noImplicitAny.
• We could add this to TypeScript files as well.
• Now you're saying if an assignment in the constructor is conditional we'll say stuff is potentially undefined - but that might mean that users get more false-positives for potentially uninitialized/undefined errors.
  • Users can add a JSDoc cast if they need.
  • Don't need a JSDoc annotation for lateinitialized or whatever yet.
• Okay, what about doing this in TypeScript in noImplicitAny?
  • Definitely not using the old heuristic for JS - just want the constructor CFA checks.
  • As soon as you allow people to omit property types, people will ask why you can't omit the property itself.
    • As soon as you misspell an assignment in the constructor, you'd add a new declaration.
• Conclusion: 4.0-bound, TypeScript will get auto-typed property declarations.

React's jsx and jsxs

#34547

• Idea is that React wants JSX to be a totally opaque transform.
• How often can this happen realistically?
  • Depends on if there's a faster behavior for everyone to ship.
• Can just have jsx: preserve and let the bundlers take over.
  • But how do we know what the types are for JSX?
  • Using the transform sort of still implies there's an auto-import to React unless asked otherwise.
  • Even with that, you need to still have something to say "all JSX implies files are a module"
• There's a big question mark on who does the JSX transform: is it bundlers, is it TypeScript?
  • Have to discuss, clarify what work needs to be done where.