Design Meeting Notes, 12/2/2022

[DanielRosenwasser]

Verbatim Module Syntax

#51479

• One aspect of the design is ESM syntax implies ESM, CJS implies CJS
  • Might be hard for existing codebases to understand.
  • Another was that it might be good to split the behavior into another flag.
    • Feels like we can split that out at a later date. But it makes sense for the behavior to be enforced as part of this flag.
• This flag intends to deprecate two flags - importsNotUsedAsValues and preserveValueImports. Does it replace them well?
  • preserveValueImports yes
  • importsNotUsedAsValues?
    • Hard to say. The erroring case doesn't seem perfectly replaced.
• Would we use this flag?
  • Totally
  • Even with all the cleanliness/maintenance that that requires?
  • Yes.
• Is it an error to specify this flag with the two old ones?
  • Probably.
• Pre-existing ESLint rules should do the right thing under this.
• The fact that our deprecation policy gives us room to say "actually we've changed our minds" makes us feel comfortable.
• Naming?
  • --verbatimImports?
    • Doesn't cover exports
  • --isolatedModules strict?
    • This flag covers different things.
    • isolatedModules comes up with rules for the most rudimentary bundler.
      • Getting fuzzier as esbuild supports more.
  • --verbatimModuleSyntax?
    • We like this - it's future-proof(?).
• We want to proceed conditional on
  • We error on using the other two flags.
  • We use --verbatimModuleSyntax

Variance-Based Comparisons Differ from Structural Comparisons

#51620

type Foo<T> = {
    method(x: T): void;
};

type Foo2<T> = {
    method(x: T): void;
};

declare const a1: Foo<(x: number) => void>;
declare const b1: Foo<(x: number | string) => void>;

// Allowed?
a1 = b1;
b1 = a1;

declare const a1: Foo<(x: number) => void>;
declare const b1: Foo2<(x: number | string) => void>;

// Not allowed - these don't rely on variance computations,
// and during the structural comparison, we will apply
// stricter variance checks between parameter types.
// because the parameter types of 'method' are callbacks.
a1 = b1;
b1 = a1;

• We compute variance and come up with one thing, but a structural comparison shows different results.
• You can insantiate generics that would produce methods with callback parameters.
  • Structurally, these are incompatible because of stricter callback checks, but we consider them to be bivariant.
  • So we are laxer on the generic version.
• Source: an issue Combination of intersections/partials causes invalid nested object type to not report error #51043
  • The fix was we started doing extra checks for weak types on the apparent type of an intersection when the source was an object.
• Can we do something with our marker types to tell?
• Is it possible that we could trigger the same covariant parameter checks when type parameter variance is computed as bivariant?

  • Maybe - but T can be used in more complicated types as well?

    type Foo<T> = {
        method(x: T[SomeOtherType]): void;
    };

• Actually, there are two trains of solving the problem that are going on in this meeting - erroring on the example in the surprisingly allowed case, and removing the error in the not allowed case.
  • Turns out main discussion point was actually the latter. The suggested solution would solve the former direction.
• No definite ideas.