Design Meeting Notes, 4/7/2021

[DanielRosenwasser]

override on static and declare Members

#43569

• We yell at you about no override on declare members, but trying to put override on declare members is an error.
• So statics?
  • Well...we've always been very lax with statics.
  • We don't even check for substitutability.
  • Also, constructors don't require an override, right?
  • Well we assume constructors are used polymorphically less than other types.
• Seems like it's safe to require now, can always loosen the restriction later.
• Would also be surprising if we didn't require it.
• No adverse effects on emit either.
• Proposed behavior is okay on declare.
• We do want to require override on statics.

Surprising Missing await Errors

#43514
#43071

• Accurate types, EXCEPT when you have indexed accesses.
  • Also strictClassPropertyInitialization.
• Could imagine saying "you have to have all the flags enabled".
• Easier thing to account for is checking for whether the thing is used in the body of an if.
• In a sense, and await is a call!
• There's another thing about the awaited object also always being truthy.
• What about the strictClassPropertyInitialization addition we spoke about a few design meetings ago?
  • Seems like start with this first.

Decorator Metadata and Decorator Updates

#43463
https://github.com/tc39/proposal-decorators
tc39/proposal-decorators#379

• Rather than doing this, could you write your own API-compatible tslib?
• People don't need arbitrary metadata helpers though.
  • We're not building the entire metadata API to get imported though.
  • Also, reflect-metadata isn't the only implementation of this API.
• Also implicit import = bad. We only did it for React because we were kind of forced to support it.
• Should we be waiting for decorators to hit stage 3 first?
  • SES proponents are trying to maximally support libraries today, not about "supporting decorators"
  • We want to play well in the SES ecosystem, but there's lots of libraries that will need to recompile themselves under this mode anyway.
  • Also don't want to add churn, new options that may confuse users.
• There are changes other than metadata that need to happen to accomodate SES.
  • Yes, but this one is harder to fix and used widely.
• So is this future-compatible with the current decorators proposal?
  • Seems like yes.
• Decorators are a very big change - may take a while before stage 3.
• Angular uses this - is front-end even the target of SES?
  • Yes, actually it's all about untrusted code, especially on the front-end.
• Yarn and npm both have a modern way to override packages within your entire tree.
  • Seems like this is a good workaround - if you are deploying to an SES environment, you can override everything with a "good" tslib.
• That gives us time to understand how this helper should function under a stage 3 decorators proposal.

importsNotUsedAsValues: preserve Doesn't Preserve Names

#43393