Feature: React 19 Upgrade - #951
Draft
wadebekker wants to merge 5 commits into
Draft
Conversation
Bumps react/react-dom to 19 across every package and project via a single root-level override, plus the dependent changes needed to actually build and run cleanly under it: - @types/react and testing-library versions bumped workspace-wide to their react-19-compatible releases - fixed react 19's removal of the global JSX namespace (JSX.Element) in core, epio-search, and block-primitives - switched block-primitives to the classic JSX transform, since its compiled output gets bundled directly into wp-admin block-editor builds, where react itself is externalized to WordPress core's own globally-provided copy but react/jsx-runtime is not - the automatic runtime was silently creating a dual-react-version conflict that crashed the block editor - pinned webpack and webpack-dev-server versions needed to keep wp/10up-theme's build working under the shifted dependency graph - bumped @wordpress/* and @10up/block-components in block-primitives to versions that declare react 19 support
propTypes/defaultProps on function components are silently ignored under react 19, so they no longer serve any purpose in these two projects. Removes the prop-types dependency entirely and disables the now-permanently-unsatisfiable react/prop-types eslint rule for both projects.
Regenerated package-lock.json from a fully clean node_modules install rather than the accumulated result of many incremental installs made throughout the upgrade. Collapses several duplicate nested copies of @wordpress/data, @wordpress/element, and redux that had built up along the way into single shared copies.
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
pdavies88
added a commit
that referenced
this pull request
Aug 17, 2026
Three things the v1 line needs before it can ship. **The v1 release workflow.** `changeset publish` tags `latest` by default, even when publishing a lower version number — so once v2 is out, releasing v1 through the existing workflow would silently move `latest` backwards and every fresh `npm install @headstartwp/core` would resolve to v1. Adds release-v1.yml, triggered by pushes to the `v1` branch, publishing via a new `publish:v1` script that passes `--tag latest-v1`. Consumers pin the line with `@headstartwp/core@latest-v1`. It deliberately has no plugin-release job: the WordPress plugin is published from trunk and develop, and pushing it from here would race those branches for the same destination repository. **Node 24 baseline.** .nvmrc and the root `engines` move to 24, and every workflow moves to it — unit-tests was still running a [16.x, 18.x, 20.x] matrix, which is two EOL releases and one about to be. Note this is the monorepo root, which governs contributors and CI; it is not a published package, so it does not change what consumers must run. The v1 packages deliberately keep no `engines` field, because raising the floor in a minor would strand exactly the pages-router users this line exists to support. **Dependency refresh.** No minor has shipped in about four months, so `npm update` was four months stale: 33 in-range updates applied, now down to 2. Deliberately in-range only — the 37 major-version jumps behind (storybook 8 -> 10, commitlint 13 -> 21, the @wordpress/* line, jest 29 -> 30) are a separate modernisation effort and would put the "still supports the pages router" guarantee at risk in a release whose whole point is stability. One blocker had to be cleared first: `npm update` failed with ERESOLVE because block-primitives pinned @testing-library/react ^14 while core and next were on ^16. Aligned to ^16.3.0, which is the same split PR #951 fixed on the v2 line. Verified: core 46/46 suites / 247 tests, next 28/28 / 113 tests, block-primitives 2/2, core and next build and lint clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of the Change
Upgrades the entire monorepo — all 5 published packages and all 8 example/test projects — to React 19, via a single root-level
overridesblock plus the supporting changes needed to actually build and run cleanly under it.@types/react/@types/react-domand testing-library versions bumped workspace-wideJSX.Element) incore,epio-search, andblock-primitives@wordpress/*and@10up/block-componentsinblock-primitivesto versions that declare React 19 supportwebpack/webpack-dev-serverversions needed to keepwp/10up-theme's build working under the shifted dependency graph (tracked upstream:10up/10up-toolkit#479for the dev-server issue)propTypes/defaultPropsusage from the two multisite Pages Router projects — these are silently ignored under React 19, so they no longer served any purposepackage-lock.jsonfrom a clean install (collapses several duplicate nested@wordpress/*/reduxcopies that accumulated across the many incremental installs made while working through this)A real bug found and fixed, not just a version bump
Adding a Universal Block (
tenup/hero) in the WordPress block editor crashed withObjects are not valid as a React child. Root cause:block-primitivescompiled its JSX using React 19's "automatic" runtime, which bundles its own copy ofreact/jsx-runtime. WordPress's own build tooling (@wordpress/dependency-extraction-webpack-plugin) externalizesreact/react-domto WordPress core's globally-provided React, but has no equivalent handling forreact/jsx-runtime— so the block's bundle ended up creating elements tagged by React 19 that got handed to WordPress core's actual React 18.3.1 reconciler, which doesn't recognize them as valid.Fixed by switching
block-primitivesto the classic JSX transform (React.createElement), which resolves through the externalized global consistently. Confirmed fixed end-to-end: the Hero block now works correctly in both the wp-admin editor and the headless Next.js frontend, with zero console errors.Testing done
npm run build/npm run test/npm run lint— clean (15/15, 7/7, 14/14) from a fully freshnode_modulesinstall, not just incrementally@10up/block-components)Out of scope/Not yet covered in this PR
docs/(Docusaurus) — not part of this workspace, left on React 18Test Plan
npm install && npm run build && npm run test && npm run linttenup/heroblock still works in wp-adminChangelog Entry
Credits
Props @wadebekker
Checklist: