Skip to content

Conversation

@Tobbe
Copy link
Member

@Tobbe Tobbe commented Dec 10, 2025

Running in to this issue: facebook/react#31824

Also copying these notes from redwoodjs/graphql#9727 as they provide good background on why we don't pin the dependency, like we do for most other deps

Fixes community.redwoodjs.com/t/you-must-register-a-usemutation-hook-via-the-graphglhooksprovider/5604. This problem is very similar to the Babel issues we were seeing a few months ago or so.

Dependencies that are used across the ecosystem are a poor choice for pinning because it results in node modules being hoisted in unpredictable ways.

The current problem in the forum post is:

  • we pin dependencies that our framework packages also use like @types/react in a CRWA
  • we upgrade @types/react in the framework packages, but CRWA apps don't get upgraded and still request an older version
  • node module nesting ensues because yarn tries to make everyone happy, but has to do so via the node modules linker
  • the wrong node module gets required somehow because there's now two ways to find it (what the user in the forum was experiencing)

Here's the difference in nesting before/after aligning the versions of @types/react:

% ls ./node_modules/@redwoodjs/testing/node_modules/          
@apollo			@redwoodjs			@types			pretty-format		react-hot-toast
@reach			@testing-library	ansi-styles		react-helmet-async	react-is

% ls ./node_modules/@redwoodjs/testing/node_modules/
@types

What I did with Babel was use carets for packages that I found were prone to colliding with our other dependencies like Storybook. In this case we're kind of colliding with our own packages.

Originally I wanted to remove the @types/react- packages from @redwoodjs/testing's dependencies all together because CRWA projects ship with them in the web workspace now. But @Tobbe pointed out that the mailer on the api side uses React now, so removing them from @redwoodjs/testing without also adding them to the api workspace may be a bad idea. Then I realized many mailer packages have a peer dependency on React which isn't explicit provided by the api workspace. Then we started thinking about moving the react dependencies up to the root workspace to satisfy both sides, but I knew that the Docker api image focuses on the api workspace to keep the number of dependencies installed down. TL;DR this opened a can of worms I'm not ready to commit to so I settled on just carets all around for now.

@netlify
Copy link

netlify bot commented Dec 10, 2025

Deploy Preview for cedarjs ready!

Name Link
🔨 Latest commit 375306f
🔍 Latest deploy log https://app.netlify.com/projects/cedarjs/deploys/6939a4db26ea3b0008739d5d
😎 Deploy Preview https://deploy-preview-658--cedarjs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@github-actions github-actions bot added this to the chore milestone Dec 10, 2025
@greptile-apps
Copy link
Contributor

greptile-apps bot commented Dec 10, 2025

Greptile Overview

Greptile Summary

Updated React type definitions from version 18 to version 19 across all packages, fixtures, templates, and auth providers to align with the React 19.2.1 runtime upgrade completed in PR #657.

  • Upgraded @types/react from ^18.2.55 to ^19.2.7 across 24 package.json files
  • Upgraded @types/react-dom from ^18.2.19 to ^19.2.3 in applicable packages
  • Updated yarn.lock with proper peer dependency resolution (@types/react-dom@^19.2.3 requires @types/react@^19.2.0)
  • All changes are consistent and mechanical across the monorepo

Confidence Score: 5/5

  • This PR is safe to merge with no risk
  • This is a straightforward dependency type upgrade that follows the React 19.2.1 runtime upgrade from PR chore(deps): Upgrade to React 19.2.1 #657. All changes are mechanical, consistent across 25 files, and the yarn.lock properly resolves peer dependencies without conflicts.
  • No files require special attention

Important Files Changed

File Analysis

Filename Score Overview
packages/web/package.json 5/5 Updated @types/react from ^18.2.55 to ^19.2.7 and @types/react-dom from ^18.2.19 to ^19.2.3
packages/forms/package.json 5/5 Updated @types/react from ^18.2.55 to ^19.2.7 and @types/react-dom from ^18.2.19 to ^19.2.3
packages/router/package.json 5/5 Updated @types/react from ^18.2.55 to ^19.2.7 and @types/react-dom from ^18.2.19 to ^19.2.3
yarn.lock 5/5 Updated lockfile resolves @types/react to 19.2.7 and @types/react-dom to 19.2.3 with correct peer dependencies

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant PR as PR #658
    participant Pkg as package.json files
    participant Lock as yarn.lock
    participant Types as @types packages

    Dev->>PR: Upgrade React types to v19
    PR->>Pkg: Update @types/react: ^18.2.55 → ^19.2.7
    PR->>Pkg: Update @types/react-dom: ^18.2.19 → ^19.2.3
    Pkg->>Lock: Trigger dependency resolution
    Lock->>Types: Resolve @types/[email protected]
    Lock->>Types: Resolve @types/[email protected]
    Types-->>Lock: Verify peer dependency ^19.2.0
    Lock-->>Pkg: Dependencies resolved successfully
    Pkg-->>PR: All 25 files updated consistently
    PR-->>Dev: Type definitions now match React 19.2.1 runtime
Loading

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

19 files reviewed, no comments

Edit Code Review Agent Settings | Greptile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants