Design problem in new JSX transformation

React 17 introduces a new JSX transform. I found there is some problem in the TypeScript implementation

Hi! @weswigham I think this is wrong. You should not treat it as a “base” of the import. It should be a fully qualified import specifier. With the current behavior, it is impossible to make it emit like: import { jsx as _jsx } from “//cdn.example.com/my-jsx-lib/jsx-runtime.js” cause it is not possible to add a “.js” at the end of the import specifier.

This also requires the imported file to name exactly as “jsx-runtime”.

And @weswigham answered me that:

…Yeah, so that wasn’t really my choice - it’s how the react maintainers implemented the same option in the babel transform. (And we just want to match the functionality provided by babel here, without overstepping.) The runtime being accessible at ${source}/jsx-runtime and ${source}/jsx-dev-runtime, based on how the options are presented, is part of the API contract for these endpoints (probably so the import can be swapped between dev/non-dev without explicitly reconfiguring the import? I dunno, I’m guessing.).

So I believe I should post my concerns here. The current interpretation of the option importSource in the babel (or jsxImportSource in TypeScript) are not allowing import {jsx} from '//cdn.example.com/my-jsx-lib/jsx-runtime.js' because it is forcing the end of the import path to be jsx-runtime or jsx-dev-runtime

Maybe I think I should also cc @lunaruan who implemented this in babel

[lunaruan]

Hey, thanks for reporting! It seems like at some point Node will require file extensions be added to ES imports, so we’ll have to fix the import regardless. Will put up a fix for this issue soon.

[Jack-Works]

I think most of the problem has been resolved. Thanks. But I still want to remove the hardcoded jsx-runtime and jsx-dev-runtime