Comparing changes

* ci: fix e2e debug output setup See #39373 (comment). - use correct unscoped paths for both `store_artifacts` and `store_test_results` - create missing directories to avoid error noise * ci: remove unused Cypress Cloud setup It adds unnecessary noise and complexity to our CI config.

This adds support for React 19 to all Gatsby packages, while maintaining support for React 18. This is not a breaking change. You can safely upgrade to this release while staying on React 18. All packages' peer dependencies on `react` and `react-dom` have been extended from `^18.0.0` to `^18.0.0 || ^19.0.0`. All existing **stable** Gatsby functionality is intended to work with React 19. ## Upgrade Guide > [!NOTE] > **Community** plugins may not have been updated yet to support React 19, so please check their repository for the current status. All plugins managed by the Gatsby team (in the [gatsbyjs/gatsby](https://github.com/gatsbyjs/gatsby) repository) have been updated. To upgrade to React 19, first upgrade `gatsby` and all your dependencies that start with `gatsby-` to the latest version. (Check out [this guide](https://www.gatsbyjs.com/docs/reference/release-notes/upgrade-gatsby-and-dependencies/) if you need help with that.) > [!TIP] > If you use npm 7 or higher you’ll want to use the `--legacy-peer-deps` option. For example, if you use `gatsby` and `gatsby-plugin-postcss`: > > ```sh > npm install --legacy-peer-deps gatsby@latest gatsby-plugin-postcss@latest > ``` Then, [follow the React 19 upgrade guide](https://react.dev/blog/2024/04/25/react-19-upgrade-guide). No other changes are required. Please note: - Some _new_ React 19 features may not be available yet via Gatsby. - Notably, the new [document metadata hoisting feature](https://react.dev/blog/2024/12/05/react-19#support-for-metadata-tags) is disabled in Gatsby, as it conflicts with the existing [Gatsby Head API](https://www.gatsbyjs.com/docs/reference/built-in-components/gatsby-head/) - Gatsby [Partial Hydration](https://www.gatsbyjs.com/docs/how-to/performance/partial-hydration), an **experimental** feature for three years now, is known to be **incompatible with React 19** at this time. If you rely on this feature, do not upgrade to React 19. ## New features Gatsby now supports [React 19's new root error callbacks](https://react.dev/blog/2024/12/05/react-19#error-handling). Users can export `onCaughtError` and `onUncaughtError` from their `gatsby-browser.js` to handle errors caught by error boundaries and uncaught errors respectively: ```js // gatsby-browser.js export const onCaughtError = ({ error, errorInfo }) => { // e.g. send to an error tracking service myErrorTracker.reportError(error, { extra: errorInfo }) } export const onUncaughtError = ({ error, errorInfo }) => { // e.g. send to an error tracking service myErrorTracker.captureException(error, { extra: errorInfo }) } ``` In development, these errors also appear in Gatsby's Fast Refresh error overlay. These callbacks are only invoked in React 19. ## Implementation This PR configures CI to run the existing `development-runtime` and `production-runtime` e2e test suites against both React 18 and 19. ### fix([gatsby-plugin-image](https://www.gatsbyjs.com/docs/reference/built-in-components/gatsby-plugin-image/)): work around a regression in React 19 core There is an undocumented change in behaviour in React 19: facebook/react#31660. Basically, in previous versions, an unchanged `dangerouslySetInnerHTML.__html` would not result in a re-render, but in React 19 referential equality of the `dangerouslySetInnerHTML` object is used instead. The `gatsby-plugin-image` implementation fundamentally depends on the previous behaviour, so that our own `innerHTML` updates do not get clobbered by a reset to this `dangerouslySetInnerHTML` placeholer value. As a workaround, this commit memoizes the object with `useMemo()`. This is safe for React 18 as well. ### fix: replace usages of `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` 😶 There was one use of `React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED?.ReactDebugCurrentFrame?.getCurrentStack()`. React 19 introduced `React.captureOwnerStack()` which we'll now use instead if available. ### fix: avoid conflicts between Gatsby Head API and new [React 19 document metadata feature](https://react.dev/blog/2024/12/05/react-19#support-for-metadata-tags) There are two conflicts here: 1. React 19 no longer allows rendering a second `<html>` or `<body>` element anywhere in the tree. 2. React 19 hoists document metadata tags (`<title>`, `<meta>`, etc.) automatically into the `<head>`, with similar semantics as Gatsby's Head API. These both conflict with Gatsby's Head API implementation, which renders all these elements in a hidden `<div>`, which it later finds to extract, merge, and apply attributes on the actual DOM nodes. We work around this with two techniques: - Tags that ultimately belong in `<head>` are wrapped in an `<svg>` tag 😬, which prevents React 19's new mechanism from hoisting them, letting Gatsby process them as before. - We monkey-patch `React.createElement` (when using React 19 only) to intercept `<html>` and `<body>` elements within the Gatsby Head API context, replacing them with `<div data-original-tag="html|body">` stand-ins. This allows Gatsby to extract attributes from these elements without triggering React 19's restrictions. #### Future work - Expose less magical `<HtmlAttributes>` and `<BodyAttributes>` components (or some other API) to allow phasing out the nonstandard `<html>`/`<body>` magic? - Refactor Gatsby Head API implementation to use the native React document metadata functionality when available? or remove this part of the Gatsby Head API entirely in favour of users leveraging React's feature directly - Remove `<svg>` workaround by augmenting the `React.createElement` monkey-patch to check for `<title>`, `<meta>`, etc.? One workaround is better than two, maybe. ### Experimental Partial Hydration incompatibility with React 19 Gatsby's experimental Partial Hydration feature has been flagged as experimental for about three years and relies on React's experimental `react-server-dom-webpack` package APIs that were substantially overhauled between React 18 and 19 as part of the RSC stabilization effort. Gatsby has been pinned to version `0.0.0-experimental-c8b778b7f-20220825` for years. The feature used experimental RSC APIs that no longer exist or are incompatible with React 19 for various reasons. Porting to React 19's stabilized RSC architecture would require _substantial effort_ and the feature has seen limited adoption. It took massive research and iteration for other frameworks to reach RSC maturity and much of the effort was in underlying bundlers. It's very unlikely Gatsby will tackle this. The problematic import (`react-server-dom-webpack`) was previously imported statically at the top of the module, causing React 19 projects to encounter import errors even when not using Partial Hydration. In this PR, we simply moved the import to a conditional async import that only loads when Partial Hydration is actually enabled via the (existing) opt-in flag. This allows the majority of Gatsby projects to safely upgrade to React 19 while allowing projects that have opted in to Partial Hydration to continue using it by remaining on React 18 while still being able to receive Gatsby upgrades. --------- Co-authored-by: Michal Piechowiak <[email protected]>

…39396) fix(deps): bump `body-parser` to resolve `qs` vuln See GHSA-6rw7-vpxm-498p. Fixes #39394.

A transitive dependency made a breaking change in a patch: https://github.com/unjs/unstorage/releases/tag/v1.17.4.

* fix: set node.js version range to 18 + 20 + 22 + 24 This isn't a breaking change, as the previous range was `>=18.0.0`, which is inclusive of all versions that currently exist. The purpose of this change is to ensure that our current ranges don't automatically start claiming to support node.js 26 (and so on) the day it is released.

This reverts commit aea34d8.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Aug 27, 2025

Commits on Aug 28, 2025

Commits on Nov 14, 2025

Commits on Nov 27, 2025

Commits on Jan 22, 2026

Commits on Jan 26, 2026

This comparison is taking too long to generate.

Uh oh!