fix: restore @types/react hoisting for pnpm 10#2057
Conversation
…scape pnpm 10 changed `publicHoistPattern` default from `['*types*', '*eslint*']` to `[]`, removing the firewall that prevented TypeScript module resolution from escaping the monorepo boundary. When agents-docs imports files from agents-api (cross-boundary imports for OpenAPI spec and model utilities), TypeScript resolves @types/react from those external locations by walking up ancestor directories. Without @types/react hoisted at the monorepo root, the walk escapes past agents/node_modules/ into any parent directory that might have a stale node_modules with a different @types/react version — causing dual-type compilation errors. Adding targeted publicHoistPattern for @types/react and @types/react-dom restores the monorepo-root firewall. The pattern is intentionally narrow (not @types/*) to avoid hoisting @types/bun which pollutes the global fetch type with Bun-specific extensions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR Review Summary
(0) Total Issues | Risk: Low
This is a clean, well-targeted infrastructure fix with no actionable concerns.
🔴❗ Critical (0) ❗🔴
None.
🟠⚠️ Major (0) 🟠⚠️
None.
🟡 Minor (0) 🟡
None.
💭 Consider (0) 💭
None.
✅ APPROVE
Summary: This is a well-reasoned, minimal fix for a real TypeScript resolution issue caused by pnpm 10's breaking change to publicHoistPattern defaults. The narrow scope (only @types/react and @types/react-dom, not @types/*) is deliberate and correct — hoisting @types/bun would pollute global types and break ai-sdk-provider. The PR description is thorough, the test plan is comprehensive, and the change is configuration-only with no lockfile impact. Ship it! 🚀
Discarded (4)
| Location | Issue | Reason Discarded |
|---|---|---|
pnpm-workspace.yaml |
Narrow publicHoistPattern is well-reasoned | Positive validation, not an issue |
pnpm-workspace.yaml |
No lockfile changes as expected | Positive validation, not an issue |
.github/composite-actions/install/action.yml |
Cached node_modules may have stale symlink layout | Speculative, reviewer notes "likely benign" and pnpm should auto-detect |
pnpm-workspace.yaml |
Configuration placement is correct for pnpm 10 | Positive validation, not an issue |
Reviewers (1)
| Reviewer | Returned | Main Findings | Consider | While You're Here | Inline Comments | Pending Recs | Discarded |
|---|---|---|---|---|---|---|---|
pr-review-devops |
4 | 0 | 0 | 0 | 0 | 0 | 4 |
| Total | 4 | 0 | 0 | 0 | 0 | 0 | 4 |
1 participant
Summary
publicHoistPatterntopnpm-workspace.yamlto hoist@types/reactand@types/react-domto the monorepo root@types/reactcompilation errors inagents-docsProblem
pnpm 10 changed
publicHoistPatterndefault from['*types*', '*eslint*']to[](pnpm v10 release notes). This removed the@types/reactsymlink at the monorepo root that previously acted as a TypeScript resolution firewall.agents-docshas cross-boundary imports fromagents-api/(OpenAPI snapshot, model utilities). When TypeScript resolves@types/reactfrom those external file locations, it walks up the directory tree:This creates two incompatible React type instances (v18 + v19) in the same compilation = type errors.
Fix
Add targeted
publicHoistPatterninpnpm-workspace.yaml(the canonical pnpm 10 location for this setting):The pattern is intentionally narrow (not
@types/*) because hoisting@types/bunpollutes the globalfetchtype with Bun-specificpreconnectextension, breakingai-sdk-providertypecheck.After applying
Contributors need to run
pnpm installafter pulling this change to regenerate the hoisting symlinks. No lockfile changes.Test plan
pnpm --filter agents-docs typecheckpassespnpm typecheck(full monorepo, 15/15 tasks) passespnpm format:checkpassesnode_modules/@types/reactexists at monorepo root after install@types/bunis NOT hoisted (prevents fetch type pollution)🤖 Generated with Claude Code