Update next and react versions

[Camillebzd]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
monode	Ready	Preview, Comment	May 8, 2026 2:43pm

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​react@​19.2.4 ⏵ 19.2.6
	npm/​react-dom@​19.2.4 ⏵ 19.2.6

View full report

[greptile-apps]

Greptile Summary

This PR bumps react and react-dom from 19.2.4 to 19.2.6 (patch) and updates pnpm-workspace.yaml to exclude the new versions from minimum release age checks; next itself is not changed despite the PR title. The pnpm-lock.yaml regeneration introduces duplicate YAML map keys — every @next/* package at 16.2.6 appears twice as a top-level entry, and numerous @img/sharp-* and @tailwindcss/oxide-* stanzas gain a duplicate libc: field — which is invalid per the YAML spec and should be resolved before merging.

• react and react-dom receive a minor patch bump (19.2.4 → 19.2.6); this is a low-risk change with no API surface changes expected.
• The lock file contains duplicate YAML keys for @next/* packages and duplicate libc: fields in several native-binary stanzas, suggesting a pnpm version mismatch during regeneration.

Confidence Score: 3/5

The react/react-dom patch bump is safe, but the lock file contains malformed duplicate YAML keys that could cause inconsistent behavior in tools that parse it independently of pnpm.

The lock file contains duplicate top-level entries for all @next/* packages and duplicate libc: keys in multiple native-binary stanzas. While pnpm's own parser may silently accept the last occurrence, external tooling (security scanners, dependency auditors, CI lock-file integrity checks) could read different entries, potentially masking vulnerabilities or breaking audit steps. The lockfile should be cleanly regenerated before merge.

frontend/pnpm-lock.yaml requires attention due to duplicate package entries and duplicate YAML keys introduced during regeneration.

Important Files Changed

Filename	Overview
frontend/package.json	Bumps react and react-dom from 19.2.4 to 19.2.6 (patch update); next remains at 16.2.6.
frontend/pnpm-workspace.yaml	Adds react@19.2.6 and react-dom@19.2.6 to minimumReleaseAgeExclude, replacing the old 19.2.4 entries to match the updated versions.
frontend/pnpm-lock.yaml	Lock file regenerated with updated react/react-dom peer resolutions, but introduces duplicate YAML map keys — full package entries for @next/env@16.2.6 and all @next/swc-* packages appear twice, and multiple @img/sharp-* and @tailwindcss/oxide-* packages have duplicate libc: fields within their stanzas.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[PR: Update next and react versions] --> B[package.json]
    A --> C[pnpm-workspace.yaml]
    A --> D[pnpm-lock.yaml]

    B --> B1[react: 19.2.4 to 19.2.6]
    B --> B2[react-dom: 19.2.4 to 19.2.6]
    B --> B3[next: 16.2.6 unchanged]

    C --> C1[Add react@19.2.6 to minimumReleaseAgeExclude]
    C --> C2[Add react-dom@19.2.6 to minimumReleaseAgeExclude]

    D --> D1[Update all react peer dependency resolutions]
    D --> D2[Duplicate @next/* package entries added]
    D --> D3[Duplicate libc: keys in @img/sharp-* stanzas]

Loading

Comments Outside Diff (1)

1. frontend/pnpm-lock.yaml, line 205-208 (link)

   Duplicate package entries in lock file

   The regenerated lock file contains duplicate top-level YAML map keys for every @next/* package at 16.2.6 (e.g., @next/env, all @next/swc-* variants), as well as duplicate libc: fields within stanzas for several @img/sharp-* and @tailwindcss/oxide-* packages. Duplicate keys are undefined behavior in the YAML spec — most parsers silently keep only the last occurrence, but security scanners, audit tools, and some CI dependency-resolution steps that parse the lockfile independently of pnpm could see inconsistent or missing entries. This suggests the lockfile was regenerated with a mismatched pnpm version or via a manual pnpm install that merged two lock files. It should be regenerated cleanly (delete the lock file and run pnpm install from scratch, or ensure a single consistent pnpm version is used) before merging.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: frontend/pnpm-lock.yaml
   Line: 205-208
   
   Comment:
   **Duplicate package entries in lock file**
   
   The regenerated lock file contains duplicate top-level YAML map keys for every `@next/*` package at `16.2.6` (e.g., `@next/env`, all `@next/swc-*` variants), as well as duplicate `libc:` fields within stanzas for several `@img/sharp-*` and `@tailwindcss/oxide-*` packages. Duplicate keys are undefined behavior in the YAML spec — most parsers silently keep only the last occurrence, but security scanners, audit tools, and some CI dependency-resolution steps that parse the lockfile independently of pnpm could see inconsistent or missing entries. This suggests the lockfile was regenerated with a mismatched pnpm version or via a manual `pnpm install` that merged two lock files. It should be regenerated cleanly (delete the lock file and run `pnpm install` from scratch, or ensure a single consistent pnpm version is used) before merging.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
frontend/pnpm-lock.yaml:205-208
**Duplicate package entries in lock file**

The regenerated lock file contains duplicate top-level YAML map keys for every `@next/*` package at `16.2.6` (e.g., `@next/env`, all `@next/swc-*` variants), as well as duplicate `libc:` fields within stanzas for several `@img/sharp-*` and `@tailwindcss/oxide-*` packages. Duplicate keys are undefined behavior in the YAML spec — most parsers silently keep only the last occurrence, but security scanners, audit tools, and some CI dependency-resolution steps that parse the lockfile independently of pnpm could see inconsistent or missing entries. This suggests the lockfile was regenerated with a mismatched pnpm version or via a manual `pnpm install` that merged two lock files. It should be regenerated cleanly (delete the lock file and run `pnpm install` from scratch, or ensure a single consistent pnpm version is used) before merging.

_{Reviews (1): Last reviewed commit: "merge main" | Re-trigger Greptile}