Design Meeting Notes, 3/27/2020

[DanielRosenwasser]

Breaks from 3.9

• 3.9 introduces breaks, and we found a bunch in the community - but they look like they're purely better.
• bottender
  • input parameter constrainted to a union

  • type B = Yadda | Wakka | any; // really an alias to `any`
    
    function fn<T extends B(x: T) {
        takeObj(x);
    }
    
    function takeObj(thing: Record<string, any>) {
        // ...
    }

  • Used to work in 3.8.3, now gets an error because x isn't treated as much as any.
  • Seems good.
• CSSBlocks
  • isAttributeArgs(x) is a type guard.
  • Guarded down to discriminants that are in confict, goes down to never.
  • Definitely a bug.
• xstate
  • We do more work to explore conditional type constraints, but now we go off the rails.
  • Meta: how did you know what caused this?
    • Only two places we report that: base constrain detection and type instantiation.
    • Is there any way to figure out why this occurs?
      • Like debugging without a debugger or println
        • (aside: someone pronounces "println" as "print len")
• webpack
  • A bunch of interfaces that extend Object
    • Pretty unnecessary
  • Whatever, anyway, config?: string intersected with config: number.
  • Now we look at the flat properties when relating from an intersection.
  • Now we catch that the effective property list is useless.
• Conclusion: these largely seem good.

Array Method Definition Changes

• There are methods that have super duper weird behavior - concat and flat etc.
• People want to improve them, but often have unpredictable consequences in existing code.
• Really need to think through before accepting these changes.

awaited Type

#35998

• Had to back changes out - but 3.7 regressions have been fixed.
• Do people run into this at all?
• The cure may be worse than the disease given the existing code out there.
• Whenever we think of Promise<T>, that T really should never be a Promise<...>
  • We assume that instantiation is just replacement.
• If we never want to see Promise<Promise<...>>, we have to rethink everything about our implementation.
• We never intended for users to use this operators, but we did want library authors to be able to express their promises too.
• The type parameter that Promise takes really needs to be considered special in some capacity.

--emitExtension and --noImplicitExtensionName

#35148

• Is this the way we wanna do this?
  • One member: no
  • Configures Node resolution
  • No reasonable default for a given runtime
  • Works pretty well, and what we have for bundlers "works" because it's the common subset.
  • But for Node's resolution (that common subset), these things don't exist
• Could imagine 2 new resolution options
  • Node 13 experimental/Node 14 non-experimental
    • Understand export maps
  • Browser
    • Root-level import maps
      • More in-flux than the Node stuff.
  • Bundlers are mixing and matching behaviors of both
• A single module resolver has tradeoffs that might not always succeed.
• Now you need to customize endlessly
  • "But what if my bundler emits outputs whose extension reflect their inputs?"
    • Can't model this.
• Users want to be able to say "I wanna run under X" not "give me 13 options".
• Reason we haven't implemented any of this is the flux of these new strategies.
• Stuff feels too in-flux
  • Could have experiments to get early ideas of how these work.
• Might want to also consider some support for supporting both ESM and CJS at the same time.
• Conclusion: would prefer new moduleResolution flags, not clear we want 3 separate new ones, not clear how they should all behave.

Expanded Generic Source Intersections

#37537

• Lots more breaks in the community suite
• Will have to understand what exactly is improved here.