fix(router-modules): bump peer @modular-react/* to 2.x range#34
fix(router-modules): bump peer @modular-react/* to 2.x range#34diogomiguel merged 1 commit intomainfrom
Conversation
`@tanstack-react-modules/*` and `@react-router-modules/*` packages still declare `@modular-react/core: ^1.2.0` (and `react: ^1.2.0` on runtime/ testing) in their peer ranges, even though the actual code in those runtimes consumes the React Context produced by `@modular-react/react@2.x` in the host's `<Manifest.Providers>` tree. When a consumer installs `@modular-react/core@^2.0.0` alongside, npm hoists 2.x for the host but nests `core@1.x` + `react@1.x` under each router-modules package — two copies of `@modular-react/react` means two distinct React Context objects, and `useZones` / `useNavigation` / `useRouteData` silently return undefined because the consumer reads the wrong context. Same peer-descriptor correction we did for journeys/react in #33, applied to all six router-modules packages. Testing packages also bump their peer of `@modular-react/journeys` from `^1.0.0` to `^1.0.1` to match the upstream peer correction. No behavior change.
|
Warning Rate limit exceeded
To continue reviewing without waiting, purchase usage credits in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Follow-up to #33. Same peer-descriptor drift on the router-modules side: all six
@tanstack-react-modules/*and@react-router-modules/*core/runtime/testing packages still declare@modular-react/core: ^1.2.0(and@modular-react/react: ^1.2.0on runtime/testing), even though the runtime hooks consume React Contexts produced by the host's@modular-react/react@^2.xinstall.@tanstack-react-modules/corecore: ^1.2.0core: ^2.0.0@tanstack-react-modules/runtimecore: ^1.2.0,react: ^1.2.0core: ^2.0.0,react: ^2.0.0@tanstack-react-modules/testingcore: ^1.2.0,react: ^1.2.0,journeys: ^1.0.0core: ^2.0.0,react: ^2.0.0,journeys: ^1.0.1@react-router-modules/corecore: ^1.2.0core: ^2.0.0@react-router-modules/runtimecore: ^1.2.0,react: ^1.2.0core: ^2.0.0,react: ^2.0.0@react-router-modules/testingcore: ^1.2.0,react: ^1.2.0,journeys: ^1.0.0core: ^2.0.0,react: ^2.0.0,journeys: ^1.0.1CHANGELOG entry added under
Unreleased.Why this matters for consumers
After #33 + the manually-published
react@2.0.1/journeys@1.0.1, autopilot's install resolves cleanly forjourneysbut the router-modules tree still nests an oldcore@1.5.0+react@1.4.0because of their stale peer ranges:Two
@modular-react/reactcopies means two distinct React Context objects: the host's<Manifest.Providers>produces a Provider against the 2.x context;@tanstack-react-modules/runtime'suseZones/useNavigation/useRouteDatareads against the 1.x context. The hooks silently returnundefinedand zone-driven layouts render empty.The runtime code already works against
@modular-react/core@2.x— the only thing required is the peer range correction.Test plan
pnpm installat the workspace root resolves cleanly (workspace deps useworkspace:*)git diffshows only peer ranges + CHANGELOG entry — no behavior code touchednpm install @modular-react/core@^2.0.0 @tanstack-react-modules/runtime@latestresolves to a single hoistedcore@2.x+react@2.xeverywhere