[@emotion/react] Regression for importing types in v11.14.0

[emmenko]

Current behavior:

In v11.13.5 the import @emotion/react/types/jsx-namespace works as expected.

In v11.14.0 the import @emotion/react/types/jsx-namespace does not work.

To reproduce:

https://codesandbox.io/p/sandbox/emotion-typescript-example-forked-dsrcnf

If you change the version of @emotion/react to v11.13.5 it works.

PS: the issue might be related with the changes in #3284

Expected behavior:

The import @emotion/react/types/jsx-namespace should work.

Environment information:

• react version: 17.0.2
• @emotion/react version: 11.14.0

[Andarist]

Tbf, @emotion/react/types/jsx-namespace was never something you were supposed to have access to. It also didn't work before #3281 (and before #3284 ) with moduleResolution: node16. It only worked in your case because you have relied on overly-permissive moduleResolution: node.

Why do you even need to access this type? We might expose it from some entrypoint if a compelling use case is presented

[emmenko]

Hey @Andarist ,

Thanks for the quick feedback. We're not using the import directly, it's an "artifact" of the production bundles (using Preconstruct).

Example:

What moduleResolution are we supposed to use?

[Andarist]

moduleResolution: node16 (or moduleResolution: nodenext) is a more future-proof setting.

What's the input code that generates this declaration file? I can't repro it on this simple TS playground. The generated dts is:

export default function Tab(): import("react").JSX.Element;

[emmenko]

We are compiling with Preconstruct and also have a Babel config, which includes for example @emotion/babel-plugin and the @babel/preset-react which is configured with { importSource: '@emotion/react' }.

I assume that would affects how the import is generated?

Note that these bundles are from our library component. Would it make sense to use moduleResolution: bundler?

Do you have any other clue or suggestion on what would be a recommended setup?
For instance, if I try moduleResolution: node16, there are other errors like:

Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'.

or

The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("vite")' call instead.
To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field `"type": "module"` to '<path>'.

import type { Plugin } from 'vite';

[emmenko]

I did some testing by using the moduleResolution: bundler. The generated import changes to:

import("@emotion/react/jsx-runtime").JSX.Element;

Would that be more correct / expected?

[Andarist]

Babel configs don't matter much for dts generation.

I did some testing by using the moduleResolution: bundler. The generated import changes to:

It should be fine in your case, given you compile the actual JS output using Preconstruct. It should fix up all of the extensionless import statements etc in your output.

Would that be more correct / expected?

import("@emotion/react/jsx-runtime").JSX.Element; looks correct to me. @emotion/react/jsx-runtime is and was a public entrypoint.

---

That said, I could still use a repro case for the original problem. Maybe there is something I could to to avoid this problem on our side. But I guess your problem isn't really easily fixable because it's caused by a library already compiled with an older version of Emotion installed. We could only try to add this path to increase the backward compatibility but I'm not that inclined to do that right now. Those changes were released months ago and you are the only one reporting this 😅

[emmenko]

Thanks!

We'll go for the bundler option then. I was able to amend the new type errors (most of them legit) so I think this unblocks us to upgrade to v11.14.0.

If I encounter any more related issues, I'll reach out again.

[emmenko]

PS: now I'm a bit confused. I can't seem to reproduce the issue locally anymore without the moduleResolution change.

What's weird is that one of our component library doesn't seem to have the issue (according to the published artifacts)

while another component library in a separate repository has the issue in the published artifacts.

The setup for both repository is essentially the same.

Anyway, we'll try to switch to moduleResolution: bundler regardless and see how it goes.