Design Meeting Notes 11/1/2019

[DanielRosenwasser]

Dependently Narrowing Element Accesses

Guest: @jack-williams

#33014
#33237

• Lots of people used to be able to write code where narrowing down based on literals would allow you to be assignable to an indexed access.
  • Then we tightened our checking and we broke people.
• The idea was, after being able to narrow a specific expression of a generic type, we'd be able to keep that information in mind and track that.
• But control flow analysis only tracks narrowed types - this work requires a separate set of information that keeps the type of an expression the same while keeping in mind that the expression can be used to index into an object.
  • Would need to add quite a bit in CFA.
  • Had an idea of only walking up lexical narrowings (instead of using control flow analysis), but that behavior is quite different and doesn't track the negative cases of narrowing well.
  • Often get issues when CFA join points don't union the types back together.

Narrowing from Narrowed Unions

Guest: @jack-williams

#30593

• Mostly implementation concerns - the current scheme doesn't quite work.

The Language Service Build

(Orta)

#33584

• Want to create a package for what people get when they write require("typescript").
  • This can be a fairly heavy package.
• A lot of this would've been avoided if we used, uhhhh modules
• If we're doing what we're doing here, would it conflict with what we should eventually do?
  • Seems like there's paths forward.
• But you might actually end up with duplicates in your eventual tree dependency tree.
  • Still can end up with lots of duplicate code.
• Can we split into modules?
  • One of the problems last time we did the conversion was that checker.ts got 200-400 lines of imports.
    • Well checker.ts is already over 35K so what's the big deal?
      • 👏👏👏👏👏👏
• Follow-up: let's create a modules sub-comittee! 🙃
  • Figure out a plan and timeline for converting to modules. 🎉

Avoiding Exponential Spreads

(Wesley)

#34853

• People like to use this funny pattern for conditionally adding properties to an object literal.
  • But, each of these types builds up a type from the initial object ({}) and spreads it with {} | { [[some-key]]: SomeType}, which doubles up the number of types in the calculated union.
• Also funny - the perfectly accurate nature of this behavior isn't ever observed because it results in the {} type due to union subtype reduction!
• PR special-cases to say that spreading in {} | SomeObjectType, it just makes all the properties optional.
• What happens when you might overwrite a property?
  • Doesn't make the property optional unless the original object's property already was optional.

React createElement Changes

#34547

• React proposed changing VDOM node format and creation

• Take in children as part of props instead of variadic nature

• change to shape of the factory function

• needs new emit mode, maybe new check mode

• affects our jsx and jsxFactory options as well

• React's motivation was to allow spreading in children but discourage spreading key

• Why is it hard for us to support new emit mode?

  • "react18"?

  • Migration strategy: change default over TS releases?

  • should we move our react support into a compiler plugin?

    • existing concerns with compiler plugins affecting the canonicity of TS (([[meta: this line is how you know @uniqueiniquity wrote this section of the notes]])

  • Maybe

    Note: name is 'react12' instead of 'react-legacy' in case this   happens again
    
    -----------|-3.8----3.9----4.0
    'react'    | Old    Error  New
    'react18'  | New    New    New
    'react12'  | Old    Old    Old
    

• Do we need to change our checking?

  • If so, do we need pragmas in declaration files or do we need to inspect dependencies?

• Unclear whether deprecation strategy of emit flag will take or not.