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: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@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.

Size Change: +425 B (+0.01%)

Total Size: 7.69 MB

_{compressed-size-action}

Flaky tests detected in a2fd171.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23593326378
📝 Reported issues:

• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js

I'm having a hard time following the benefit we're hoping to get from this. If it's not an issue in @wordpress/element because we import from react-dom/client, does that also imply that the @wordpress/element export isn't actually using the shared global?

If it's not an issue in @wordpress/element because we import from react-dom/client, does that also imply that the @wordpress/element export isn't actually using the shared global?

@wordpress/element actually bundles the react-dom/client code for createRoot and hydrateRoot. In React 18 this is just a tiny wrapper that disables the warning (by setting a global variable), calls the createRoot on the shared ReactDOM global and then enables the warning again.

So, element uses the shared global, but also bundles some react-dom code.

I'll check what React 19 does, I suspect it's very different than React 18.3.1.

I'll check what React 19 does, I suspect it's very different than React 18.3.1.

With React 19, as we have it in #61521, the situation is much worse and this PR will solve a much bigger problem.

react-dom@19 doesn't export createRoot, so there is no warning to fix. But also ... no createRoot. react-dom is a tiny package, with helpers like createPortal or flushSync, generally code that is useful both in browser and on server.

The entire reconciliation engine is in react-dom/client, exposed by createRoot and the render method on a root object.

Because we externalize only react-dom and not react-dom/client, the entire reconcilation engine is bundled inside @wordpress/element. The package is now over 1MB when not minified.

If we want to keep one react-dom library, we'll have merge react-dom and react-dom/client together. Then we'll again have one big script with all things React, and element will be a tiny reexport package.

If we want to keep one react-dom library, we'll have merge react-dom and react-dom/client together. Then we'll again have one big script with all things React, and element will be a tiny reexport package.

So is there follow-up work to be done there? Like, we'd update @wordpress/element to import createRoot from react-dom instead of from react-dom/client ?

Should we be going about this another way instead and adding react-dom/client as its own vendor script, more like what we're doing with react/jsx-runtime, so that @wordpress/element imports from the actual client subpath? It feels a bit wrong to be faking the package exports and importing something which doesn't actually exist in react-dom.

So is there follow-up work to be done there?

Yes, as a follow-up, we would externalize the react-dom/client imports and direct them to the window.ReactDOM global. Especially for React 19 where the impact is really big.

Should we be going about this another way instead and adding react-dom/client as its own vendor script, more like what we're doing with react/jsx-runtime.

That's another option, creating a new react-dom-client script. One WP script for each React import path.

Until React 18, there was a clear standard how a React/ReactDOM UMD script should look like, and what are the window.React and window.ReactDOM globals supposed to look at. Because React itself shipped these scripts.

But since React 19, there are no UMD scripts, just ES modules and a growing number of export paths defined in package.json. It's now up to us how we define the scripts.

We could merge the tiny packages into the big ones. The react script could ship also the three little functions (jsx, jsxs, Fragment) from react/jsx-runtime. The react-dom script could merge the client createRoot and hydrateRoot will the rest of react-dom.

It's completely up to us how we define window.React and window.ReactDOM. And how we define the mappings from import paths to external scripts in our build tools.

Yeah, I don't really have strong feelings, or not enough to be a blocker. I think this approach is fine. Especially if now ReactDOM globals aren't really a "standard" thing that we're deviating from. But it does sound like with this implementation we'll have future changes that look like import { createRoot } from 'react'; somewhere in @wordpress/element which... seems not so accurate.