Element: Make the package importable in React 19

[SirLouen]

What?

Follow up to #80024

Makes @wordpress/element importable under React 19 and widens the React peer ranges of the design-system packages like ui and theme to accept React 18 or 19.

The idea is to do a smaller working iteration rather than having to wait for a fully React 19 compliant build, which may take long and doesn't seem to be landing anywhere near WP 7.1 according to #71336

Two changes in @wordpress/element:

1. src/react-platform.ts no longer uses named imports for APIs that React 19 removed from react-dom (findDOMNode, render, hydrate, unmountComponentAtNode).
2. react, react-dom and their types move from dependencies to peerDependencies (^18.0.0 || ^19.0.0), matching every sibling package.
3. Plus the range widening (^18.0.0 -> ^18.0.0 || ^19.0.0) in the five design-system packages.

Why?

As a consumer running the design-system packages ui and theme in a React 19 app, the use case tracked in #76941. I find two problems:

Problem 1: @wordpress/element crashes at load time under React 19. React 19 deleted these four exports from react-dom, so the module fails before any code runs:

Problem 2: Declaring React as a hard dependency creates a second React. For some reason I don't understand, element is the only package in this family declaring react/react-dom as dependencies.

How?

Removing API from react-dom instead of named-importing them:

1. React 18: zero behavior change, deprecated exports keep working as before
2. React 19: names resolve as undefined. There is no scenario where this will cause regression because React 19 cannot use them by definition.

Testing Instructions

1. Create a React 18 project consuming @wordpress/element: no change: createRoot, createPortal, flushSync work, and the deprecated render/findDOMNode still function as before.

2. Create a React 19 project: import { createRoot } from '@wordpress/element' now loads and works

3. 🐞 Previously: SyntaxError at import.

[simison]

Somewhat duplicate of #80024 from @aduth ?

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: SirLouen <sirlouen@git.wordpress.org>
Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: simison <simison@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[SirLouen]

Somewhat duplicate of #80024 from @aduth ?

Good spotting, it's partially duplicate, I was hesitant on sending both versions in one commit, but yes, I'm going to remove the duplicate parts right now and just leave the compatibility layer for element that was my original intention given that #80024 fixes the most compatibility part of this patch.

Updated 👌
Probably it will need a rebase once #80024 is merged

[SirLouen]

Fresh rebase with 28e3787
Ready for review :)

[manzoorwanijk]

I think we need a changelog entry, making this one a breaking change.

[SirLouen]

I think we need a changelog entry, making this one a breaking change.

True, added the CHANGELOG.md entry. It cannot be left as a dependency; that wasn't the right call originally.

[SirLouen]

@aduth do you have any roadmap in mind to work around this?

[aduth]

I think we definitely need to fix this. Some of the other work around this (like #80706) only really indirectly solve some of the symptoms, but the impact of @wordpress/element and its compatibility in projects that use React 19 is widespread. I've been hearing similar pain from some other folks at my company about this as well.

I think it'd be good to have a review here from @jsnajdr , who has been leading a lot of the work around the React 19 upgrade.

[jsnajdr]

Why do we need to reorganize this import?

[SirLouen]

It's not a cosmetic reorganization.

React 19 removed findDOMNode, render, hydrate, and unmountComponentAtNode from react-dom.

With static named imports, those bindings must be resolvable at module link time. When a consumer loads @wordpress/element in a R19 app, the ESM loader tries to bind names that no longer exist on react-dom and throws for example:

SyntaxError: The requested module 'react-dom' does not provide an export named 'render'

Solution: A namespace import like this.

[jsnajdr]

Thanks, that makes sense. import { render } throws, but accessing a property of the namespace object (ReactDOM.render) just returns undefined.

Which ESM runtime does throw exactly this error? The native ESM resolver in Node, or in browsers? Or a bundler (esbuild or webpack) runtime?

SyntaxError: The requested module 'react-dom' does not provide an export named 'render'

[jsnajdr]

Thanks, now the element React dependencies are aligned with how other packages declare them and don't do anything special. And are compatible with React 19. Nice.