Skip to content

Pin @wordpress/react-i18n to 4.47.0 to fix trunk bundling install (ERESOLVE) - #3985

Merged
bcotrim merged 1 commit into
trunkfrom
fix-react-i18n-peer-conflict
Jun 29, 2026
Merged

Pin @wordpress/react-i18n to 4.47.0 to fix trunk bundling install (ERESOLVE)#3985
bcotrim merged 1 commit into
trunkfrom
fix-react-i18n-peer-conflict

Conversation

@bcotrim

@bcotrim bcotrim commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

Related issues

  • Related to STU-1938 (surfaced while working on it; this is a standalone trunk fix)

How AI was used in this PR

Used Claude Code to diagnose the CI failure: probed the npm registry to find the offending @wordpress/react-i18n version, reproduced the install:bundle ERESOLVE locally via a dry-run, and confirmed via GitHub commit statuses that trunk itself is red. The diff was reviewed by the author.

Proposed Changes

Trunk is currently red (E2E + Performance Metrics) and has been since 167141e6f — every build fails in the prePackage hook with:

npm error ERESOLVE
Found: react@19.2.7
peer react@"^18.0.0" from @wordpress/react-i18n@4.49.0

Root cause: apps/studio's install:bundle runs npm install --no-package-lock, so it ignores the lockfile and re-resolves @wordpress/react-i18n: ^4.47.0 against the live registry on every build. react-i18n@4.48.0/4.49.0 added a react@^18 peer, which conflicts with the repo's react 19 (since #3642). 4.47.0 is the last version with no react peer; the lockfile already pins it, which is why dev, lint, and unit tests pass — only the lockfile-less bundling install floats and breaks.

This pins @wordpress/react-i18n to exact 4.47.0 in apps/studio and apps/ui (matching the exact-pin convention already used there for other @wordpress/* packages) so the bundling install can no longer float to the broken version. Behavior-neutral — dev already runs 4.47.0.

Note: the Performance Metrics check on this PR will still show red, because that job builds the current (still-broken) trunk as its comparison baseline. That clears automatically once this lands on trunk. Since trunk is already red, merging this is strictly an improvement.

Testing Instructions

  • git checkout this branch and run the exact bundling install that CI runs:
    cd apps/studio && npm install --omit=dev --no-audit --no-fund --no-package-lock --no-progress --install-links --no-workspaces --dry-run
    
    It should exit 0 with no npm error ERESOLVE (only benign peer-override warnings).
  • On trunk the same command fails with the ERESOLVE above.

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors?
@bcotrim bcotrim self-assigned this Jun 29, 2026
@bcotrim
bcotrim requested a review from a team June 29, 2026 08:06

@epeicher epeicher left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Thanks @bcotrim for fixing this! I can confirm that I can run the cd apps/studio && npm install --omit=dev --no-audit --no-fund --no-package-lock --no-progress --install-links --no-workspaces --dry-run script without any errors, while I have the ERESOLVE error in trunk for the same command. I agree that this PR can be merged with the error in the Performance Metrics check as it runs against trunk that errors. LGTM!

Image
@bcotrim
bcotrim merged commit 245db3c into trunk Jun 29, 2026
11 of 12 checks passed
@bcotrim
bcotrim deleted the fix-react-i18n-peer-conflict branch June 29, 2026 09:05
gcsecsey pushed a commit that referenced this pull request Jun 29, 2026
…ESOLVE) (#3985)

## Related issues

- Related to STU-1938 (surfaced while working on it; this is a
standalone trunk fix)

## How AI was used in this PR

Used Claude Code to diagnose the CI failure: probed the npm registry to
find the offending `@wordpress/react-i18n` version, reproduced the
`install:bundle` ERESOLVE locally via a dry-run, and confirmed via
GitHub commit statuses that trunk itself is red. The diff was reviewed
by the author.

## Proposed Changes

**Trunk is currently red** (E2E + Performance Metrics) and has been
since `167141e6f` — every build fails in the `prePackage` hook with:

```
npm error ERESOLVE
Found: react@19.2.7
peer react@"^18.0.0" from @wordpress/react-i18n@4.49.0
```

Root cause: `apps/studio`'s `install:bundle` runs `npm install
--no-package-lock`, so it ignores the lockfile and re-resolves
`@wordpress/react-i18n: ^4.47.0` against the live registry on every
build. `react-i18n@4.48.0`/`4.49.0` added a `react@^18` peer, which
conflicts with the repo's react 19 (since #3642). `4.47.0` is the last
version with no react peer; the lockfile already pins it, which is why
dev, lint, and unit tests pass — only the lockfile-less bundling install
floats and breaks.

This pins `@wordpress/react-i18n` to exact `4.47.0` in `apps/studio` and
`apps/ui` (matching the exact-pin convention already used there for
other `@wordpress/*` packages) so the bundling install can no longer
float to the broken version. Behavior-neutral — dev already runs 4.47.0.

> Note: the **Performance Metrics** check on *this* PR will still show
red, because that job builds the current (still-broken) trunk as its
comparison baseline. That clears automatically once this lands on trunk.
Since trunk is already red, merging this is strictly an improvement.

## Testing Instructions

- `git checkout` this branch and run the exact bundling install that CI
runs:
  ```
cd apps/studio && npm install --omit=dev --no-audit --no-fund
--no-package-lock --no-progress --install-links --no-workspaces
--dry-run
  ```
It should exit 0 with no `npm error ERESOLVE` (only benign peer-override
warnings).
- On `trunk` the same command fails with the ERESOLVE above.

## Pre-merge Checklist

- [x] Have you checked for TypeScript, React or other console errors?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants