jsx: preserve Without Importing React

#41762

• This is the mode where we don't transform JSX into plain JavaScript
• TypeScript is still telling users "you still need to have React in scope" because we think it's going to become React.createElement.
• But...we're not able to reproduce the error because React has a global UMD declaration. So how are users running into this?
• Regardless, React is not going to be a global for some of these people.
• allowUmdGlobalAccess
• Seems like we trigger a look-up for React in jsx: preserve.
  • Ideally we wouldn't - everything should be defined in the JSX namespace?
• This error in jsx: preserve is useful for people who are using older React, or if the JSX namespace isn't found for some reason.
• Why is Next.js not using jsx: react17?
• Oh no, how does this affect path resolution?
  • need to import from the .jsx file when module: node12 and jsx: preserve 😬
• People are positive on decoupling the look-up.
• Do we need a flag to turn the error off?
  • Can safely disable if jsxImportSource is enabled; don't need to introduce a new flag.
  • Some justification for original design.
  • Does that make sense in a mode where you don't really need to import React?
    • Maybe yes because we look up information in the React namespace.
• Feel like we need to get a clear easy repro before we make a move.
• Plausible that jsxImportSource is enough today.

Template Literal Types as Discriminants

#46137

Someone suggested something like this ought to work.

export type Action =
    | { type: `${string}_REQUEST` }
    | { type: `${string}_SUCCESS`, response: string };

• Uncovered some issues around template literal types.
  • `${string}-bar` is not comparable with `foo-${string}`.
    • But that's not true.
  • Also, when comparing a string to a "thing" | `foo-${string}` we used to narrow the string to "thing" as opposed to the whole union.
• CheckFlags.HasLiteralType is the magic that lets templates act as discriminants.
• We loosen restrictions on comparability by saying template string types are always related unless we can immediately dismiss them.
• [[Gripes around comparability being not fully bidirectional, which doesn't capture the full picture of things.]]
  • Sometimes that's fine.
  • Can say "if there's nothing in the intersection, then they're not comparable", but almost all object types can form a valid intersection.