Improved compatibility with the upcoming @types/react for React 19

[DiegoAndai]

What: Replace global JSX with React.JSX

Why: Prepare for upcoming @types/react version which removes global JSX

How: Upgrade @types/react to ^18.2.6 which is the version that introduces React.JSX and use it to replace global JSX

Checklist:

• Documentation N/A
• Tests N/A
• Code complete N/A
• Changeset

Additional comments:

• I've updated the site's @types/react as well to match the other packages.

Let me know if there's anything I might have missed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 7b6928e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@emotion/styled	Patch
@emotion/react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[DiegoAndai]

I'm looking into the CI failures

[DiegoAndai]

• There's the following error when running yarn test:typescript: https://github.com/emotion-js/emotion/actions/runs/9812857294/job/27097742222#step:4:95. @Andarist do you know what might be happening? It seems to be a TypeScript mismatch.
• The snapshot tests are failing, but it seems like the diffs are about formatting. Not sure what I might've done incorrectly: https://github.com/emotion-js/emotion/actions/runs/9812857294/job/27097741626#step:4:16247 🤔

[Andarist]

@emmatown 18.2.6 was published at 2023-05-06T11:32:52.704Z (over a year ago). I think we might have to go forward with this PR to improve compatibility with the upcoming React 19 for Emotion 11. This is kinda a breaking change for people who might be using older @types/react versions... but I don't think we have any alternative way. It's rather hard to reliably check at type level if React.JSX exists or not to branch our logic.

[emmatown]

Hmmm, that's seems unfortunate. It doesn't seem to hard branch (with @ts-ignore of course), curious where it'd be unreliable?

[Andarist]

We can’t trust error types that result from ts-ignore: microsoft/TypeScript#58960

[Andarist]

@emmatown wdyt?

[emmatown]

Wouldn't something like this work without being susceptible to any issues like that? FunctionComponent no longer has a second legacy context parameter in React 19 types which we can check without any @ts-ignore stuff (there are probably other ways to check, this was just the first I tried) and then we use the right thing depending on the version and only those have @ts-ignore but the side where @ts-ignore does something is never used

type JSXElement = 2 extends Parameters<React.FunctionComponent<any>>['length']
  ? // @ts-ignore
    JSX.Element
  : // @ts-ignore
    React.JSX.Element

[Andarist]

Do u always have to have the answer? 😉

I applied the suggestion. I think this should be good to go now.