Unable to `import` JSX types, Error: "no interface JSX.IntrinsicElements exists", although it exists

[trusktr]

TypeScript Version: 4.1.2

Search Terms:

no interface JSX.IntrinsicElements exists

Code

This works:

namespace JSX {
    export interface IntrinsicElements {
        div: {[k: string]: any}
    }
}

const d = <div /> // <-- no error
type test = JSX.IntrinsicElements // <-- no error

playground

But this does not work:

import type {JSX} from 'solid-js'

const d = <div /> // Error: JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.

// But JSX is in scope, just that JSX expressions do not see it.
// As an example, the following non-JSX code works fine:
type test = JSX.IntrinsicElements // <-- no error

playground

Expected behavior:

It should see the definition of JSX.IntrinsicElements which is clearly present due to the import statement.

Actual behavior:

The JSX definition in the second example (imported) appears to be invisible to TS.

As you can see from both examples, only a locally-defined JSX works, but not one that is imported.

[trusktr]

If libraries could export non-global versions of JSX types, then projects could very easily have a mix of files where each file may have a different type of JSX (f.e. React in some files, Preact in others, and Solid.js in others, assuming those libs export non-global JSX types).

[RyanCavanaugh]

namespace JSX {
    export interface Element {
//  ^^^^^^
        foo: number
    }
    export interface IntrinsicElements {
//  ^^^^^^
        div: HTMLDivElement
    }
}

const d = <div></div>

[weswigham]

If libraries could export non-global versions of JSX types, then projects could very easily have a mix of files where each file may have a different type of JSX (f.e. React in some files, Preact in others, and Solid.js in others, assuming those libs export non-global JSX types).

They can. preact does this.

[trusktr]

Ahh, thanks! I never use namespace; I totally overlooked export.

[trusktr]

Turns out it actually does not work when JSX is imported, as any person organizing their code will want to do (rather than sticking everything in a single file):

This does not work:

// WHILE THIS WORKED
// namespace JSX {
//     export interface Element {
//         foo: number
//     }
//     export interface IntrinsicElements {
//         div: {foo: number, bar: string}
//     }
// }

// THIS DOES NOT
import type {JSX} from 'solid-js'

const d = <div foo={123} bar="string"></div> // JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.

playground

We can verify JSX.IntrinsicElements does exist by adding this line to the example and hovering on it:

type test = JSX.IntrinsicElements // The type exists!

It doesn't seem right for JSX.IntrinsicElements to have some sort of special treatment in terms of how it is discovered. The rule with JSX.Anything should be the same as with any other types: look up JSX.Whatever in the current lexical scope just like with any other type.

Note, JSX.IntrinsicElements is fully visible in any non-JSX code that has it in scope. JSX.IntrinsicElements is only invisible to JSX expressions.

A solution in 4.1.1 is to use jsxImportSource in every file where the JSX types are needed. Why do we need a new syntax when we already have perfectly working import type {JSX} ... syntax?

[trusktr]

Please note, the JSX type from solid-js is in a .d.ts file, and in that case TypeScript apparently does not require export inside the namespace JSX definition. TS requires export inside the namespace when the file is a module (the inconsistency is confusing).

I also tried converting that file to a .ts file, and adding export for each type inside the JSX definition, but the error remains the same (the consumer code can not find the JSX.IntrinsicElements interface).

[weswigham]

You wanna use the @jsx pragma to change the factory function used from React.createElement to whatever the factory for your library is. The JSX factory is looked up relative to the factory specified. So if your factory is h (eg, via a /* @jsx h */) we look for h.JSX.

[trusktr]

Thing is, I don't want any jsx pragma. I'm using preserve, and transpile JSX with a custom step. It does not use factories.

But still, JSX types are in scope, and TS is not picking it up. I don't think there should be any difference between an inline declaration and an import with regards to visibility. JSX shouldn't have special treatment.

[trusktr]

We have an existing import syntax, and I think it is very intuitive for that to work.

There is a new /* jsxImportSource ... */ syntax specifically for importing JSX types coupled with a factory. That is not intuitive: people don't assume to import all types with import except one special type (JSX) that requires comment syntax.

I think that

import {JSX} from `somewhere`
// or
import type {JSX} from `somewhere`

should just work. I really feel there isn't a need to make JSX a specially-treated type when it comes to making it visible in a scope.