Cannot find module 'react/jsx-runtime' when using `"module": "nodenext"`

[AndrewLeedham]

Bug Report

The experimental "module": "nodenext" ESM support does not work with "jsx": "react-jsx". Causing the following error:

Cannot find module 'react/jsx-runtime' or its corresponding type declarations.

🔎 Search Terms

esm,module,nodenext,jsx,react/jsx-runtime

🕗 Version & Regression Information

• This only occurs in nightly builds.
• I was unable to test this on prior versions because nodenext is only supported in the nightly versions.

⏯ Playground Link

Playground link with relevant code

💻 Code

Any JSX code would cause the error, this is what I used:

export default function Hello() {
    return <h1>Hello World</h1>;
}

🙁 Actual behavior

"jsx": "react-jsx" does not work with experimental ESM support ("module": "node-next").

🙂 Expected behavior

Expectation was for react-jsx to work going forward with ESM, but it cannot find react/jsx-runtime because it does not have the .js extension and/or React@17 does not have "exports": { "./jsx-runtime": "./jsx-runtime.js" } or similar in it's package.json. It looks like React@18 will add the aforementioned exports field, so I am wondering if either .js would be added when using node-next or if React@18 is a blocker for TS ESM support?

[weswigham]

We went back and forth with the react team on if we should emit the .js or not when we originally added the implicit imports, so I don't think we'll be changing that behavior, since it matches what they landed on for the official babel transform. So it seems like you'll just have to wait for/use react 18, since it seems like it's a pretty showstopping bug in react 17's experimental esm support.

[AndrewLeedham]

Fair enough. I'll close this out as wontfix then

[karlhorky]

Until React 18 is out (not very long now!) - or until you can upgrade - a workaround using sed to find and replace inside a built file to add the ESM fully-specified file path (with extension):

sed -i -e 's/jsx-runtime";/jsx-runtime.js";/g' ./build/index.js

[jeswin]

@weswigham - However, the decision (to not support the js extension) has downsides for people who just want to transpile into individual files (without bundlers).

Real world use case - there's a project to which I cannot add an import map because it's a browser extension with limited permissions. There's now no way (other than something like sed) to load the UI framework, because tsc will not emit the extension.

Keeping the JS extension will increasingly look better as more people adopt ESM. More importantly, it seems more natural.