Design Meeting Notes, 3/13/2020

[DanielRosenwasser]

Update on Intersections and Optional Properties

#37195

Relating Instances of the Same Signature

#31029

• When we have signatures that have generic type parameters, we currently erase the type parameters before we compare them.
• This is an old issue/PR, but it was pretty breaky.
• Basically, the getter/setters make the types invariant.
• This change would break completions and the like in addition to actual errors.
• Introduces some breaks in Ember
• Maybe we need a second pair of eyes
• Could we put this under strictFunctionTypes?
  • Pretty sure that Ember already is under strictFunctionTypes.
  • But that means that users can't run with strictFunctionTypes.
  • But the API inherently has problems there.
  • Means that on top of changing the .d.ts files, users would have to upgrade.
• Conclusion: try this under strictFunctionTypes, see if we can introduce a new flag instead.

Spread Elements and const assertions

#37357

• A const assertion makes things readonly.
• With a spread-in object literal, we give readonly properties.
• Tuples spread into tuples...doesn't seem to work? Is this a bug?
• Uh, looks like Proper treatment of splicing tuples in array literals #36861 fixes this.

Indexing with identical bindings of type keyof Foo

#32693

• This one keeps coming up.
• The code itself is reasonable.
• If the key on both sides is the "same" for some meaning of "same", then this feels reasonable.
  • What does "same" mean?
  • Same identifier maybe. Clearly not the same type.
• Maybe check against binary assignments.
  • But these can occur arbitrarily deep in an object literal.
  • People are typically just trying to copy over property declarations in bulk.
• How does this work when an indexing expression has a type that's the intersection of each type's key?
  • source: { A, B }, target: { B, C }, index: "B"?
• Conclusion: approved for the basic case.

skipLibCheck (and pretty?) in config files from tsc --init

#37361

• Problems: hello world check time is >1s.
• For tsc --init, we can always change this.
• Seems good to turn it on there, but we must always make sure that .d.ts files are checked somewhere.
  • DefinitelyTyped, lib.d.ts
• What else should we turn on in tsc --init?
  • --incremental?
    • Afraid people will check in their .tsbuildinfo files.
• Ask is for skipLibCheck to be included in tsc --init, not that it's turned on.
• 4 levels of tsc --init include-ness
  • Emitted with a comment
  • Emitted with a comment where it's not set to the default
  • Emitted with a value that's a default
  • Emitted with a value that's not a default
• Conclusion
  • Should have a link to the tsconfig page on our website.

[Bnaya]

hello world check time is >1s.

In many cases, that because the user have many @types/* packages in node modules that aren't relevant to the project (dev deps for example) and unless you set types: [] or manually selecting values tsc loads them all

Maybe tsc should load only what's in package.json?