Design Meeting Notes, 4/24/2020

[DanielRosenwasser]

Unexpected Breaking Changes

Deletes on Non-Optional Properties

#13783

• Ended up breaking VS Code Fix 'The operand of a 'delete' operator must be optional' errors in VS Code codebase vscode#96022
• Babylon has 23 new failures
• It seems like a good change!
• Also not clear that it only catches good stuff - prototype properties exist.
• But the messaging is that we're going to strive to keep new breaks in the beta.
• Okay, but how will users get around this when the type-checker is wrong?
  • any cast or // @ts-ignore
• Conclusion: revert for 3.9, keep in 4.0

Intersections narrowed to never with in

#38162

type MaybeFoo = {
    bar: string;
    foo?: number;
};
type AlwaysFoo = {
    foo: number | undefined;
    always: string;
};

declare const f: AlwaysFoo & MaybeFoo;
if ("foo" in f) {
    f.bar;
} else {
    // 3.8.3: f: AlwaysFoo & MaybeFoo
    // 3.9: 'f' is 'never'
    f.bar;
}

• But that's the right behavior - similar to

  type AlwaysFoo = {
      foo: number | undefined;
      bar: string;
      always: string;
  };
  
  declare const f: AlwaysFoo;

• Users were feature testing for a value on globalThis, but now have no clean way to do it.

• Conclusion: If we can special-case for globalThis, let's do it. If we can't get it in by end-of-day, back it out prior to 3.9, add it to 4.0.

deleteCount Optionality in splice

#32638

• Seems like this breaks stuff with .apply and .bind
• Wasn't an "unexpected" break in the sense that it came in post-beta
• This is technically correct, but even IE9 - IE11 has the "right" behavior of making things optional.
  • ES5.5 differences?
• Seems like it's not worth the overhead and breaks.
• Conclusion: revert before 3.9

export = and Declarations Types

#37964

• Module augmentations occur before the calculation of the global Object type, global namespaces, etc.

• Currently, code that does this crashes, but what should we do when you write this?

  import {toString} from "./foo";

  • This is a CJS-oriented feature, when you import from a CJS export = module.
  • We're "crossing the streams" - if you live in ES module land, everything's good. In this case, TypeScript gets to say "this shouldn't work".

• What's this break?

  • Have to figure it out.

• Also have to figure out other features that are impacted here.

• Conclusion: need to issue an error - the circularity has to end somewhere.

JSX Factory Updates

#34547 (comment)

• What about dev-mode paths?
• What about the dev-mode line number/character offset.
• There's a lot of details to think about - so there's a question about how configurable it needs to be, how we want to bless the workflow.
• It's already implemented in Babel, but we need to understand what users are going to be using.

Control Flow for Constructor-Initialized Properties

#37920

• We're going to enable this for all JS users, regardless of settings.
• What about TS users? Only get this under noImplicitAny?
  • Feels bad to say no, but it breaks stuff!
  • We pamper you in JS mode, give you the special strict-mode club in TypeScript, but you're on your own when strict mode is off.
    • Always had this position, but it's the safest option.