Typescript: Factory-resolved JSX namespaces

[DanielRosenwasser]

Current issues

Two recent issues we've observed relatively frequently with our JSX implementation includes the following:

1. Two separate versions of a @types/react can have differing declarations of JSX. This is problematic because the JSX namespace is global and these conflicts are surfaced to _users_ rather than library authors. This makes for a bad experience. (#17111)
2. Users can't mix and match different JSX implementations within a project. (#15386)

Mitigations

For each of the above issues respectively:

1. Currently, you can use path mapping to ensure that TypeScript has a single reference for whenever libraries import "react" or some such library
2. There is no mitigation I can think of.

Idea

@mhegazy and I have discussed this, and believe it is worth exploring the idea of resolving JSX namespaces from the same module as the factory function itself. In other words, if the JSX factory is React.createElement, TypeScript should attempt to resolve the JSX namespace from the location of the factory function itself.

Code could temporarily be defined that works in both older and newer versions of TypeScript:

namespace JSX {
    // JSX stuff goes in here.
}
export { /*...*/ }

import Temp_JSX = JSX;
declare global {
    import JSX = Temp_JSX;
}

Duplicate JSX declaration errors would still be a problem (and potentially exacerbated), but after several versions we could remove the global augmentations.

Open questions:

1. How does this work with imports/aliases of the JSX factory itself?

[mhegazy]

//cc @RyanCavanaugh

[kitsonk]

Two separate versions of a @types/react can have differing declarations of JSX. This is problematic because the JSX namespace is global and these conflicts are surfaced to users rather than library authors. This makes for a bad experience.

This isn't just a problem for React. It is a problem for any multi package project where you have cross dependencies and you are trying to work with TypeScript. Projects that have different versions of @types/node or in situations where there is a common library between the two. It would be great to see a more general solution to that.

[aronallen]

I really like this idea.