TS7026 when using JSX factory from a variable rather than import

[brawaru]

Bug Report

🔎 Search Terms

TS7026: JSX element implicitly has type 'any' because no interface 'JSX.IntrinsicElements' exists.

🕗 Version & Regression Information

• This is the behaviour in every version I tried, and I reviewed the FAQ for entries about JSX and React

⏯ Playground Link

https://codesandbox.io/s/dank-wood-cqpld?file=/src/index.tsx

💻 Code

// helping typescript to figure out the types by defining
// the return type as ...
function getPreact(): typeof import("preact") {
	// imagine that this function doesn't call require()
	// but rather uses some dynamic import, which returns
	// the same export that this call would do:
	return require("preact");
}

const { h, render } = getPreact();

function App() {
	return <div>Hello, world!</div>;
}

render(<App />, document.getElementById("app")!);

🙁 Actual behaviour

TypeScript ignores the h in the scope and errors out any vanilla JSX code because ‘no JSX.IntrinsicElements exist’. Yet it works flawlessly if you compile it ignoring types using, say, Babel. It seems that it also works correctly if you use raw h call instead of JSX.

🙂 Expected behaviour

TypeScript would be smart to figure out that h in scope is a factory method that it needs, as set by configuration (even though it's ‘imported’ weirdly) and use provided by it JSX to find IntrinsicElements and be happy with it.

[andrewbranch]

Don’t import h yourself; add jsxImportSource: "preact" to your tsconfig.json.

[brawaru]

Sorry it took long to reply!

Unfortunately, that is not going to work in my setup: I am dynamically importing Preact during the runtime, that is getPreact() returns Preact's exports. jsxImportSource implies automatic import, which is not going to work. I can, of course, use it to silence TypeScript and continue using ESBuild, which will actually use h defined in the scope, but then TypeScript starts to complain about ‘unused’ h declaration, while also not saying anything if I don't declare the h (duh).

I'd actually expect TypeScript to not expect that h can only come from the imports, but rather do what ESBuild does — use h defined within the scope; like in my situation — it is defined at the top of the file. Thus I filed it as a bug report, because it's an absolutely valid use case.

Also, I just noticed that I accidentally deleted CodeSandbox example, I re-wrote it here (will update in the issue body): https://codesandbox.io/s/dank-wood-cqpld?file=/src/index.tsx.

[andrewbranch]

I see, sorry for the confusion.

I can, of course, use it to silence TypeScript and continue using ESBuild, which will actually use h defined in the scope, but then TypeScript starts to complain about ‘unused’ h declaration

Interestingly, this can be silenced with a /** @jsx h */ pragma. Agreed this isn’t ideal though.

[WorldMaker]

Similarly to this dynamic import issue, I've been idly scratching at this at the itch of this problem trying to destructure the JSX factory function from a "context" object. I can't figure out how to type the "context" object and/or the jsx() function (or createElement() or h(), however you want to name it) on it in a way that the JSX ambient type namespace survives destructuring.

At a guess it may have something to do with how ambient type namespaces haven't kept up with other type mechanics, such as destructuring (as this example also uses due to the dynamic import). #14729 sounds like one possible solution in trying to get a lot more of the type information directly a part of and transportable with the jsx() function alone.