fix(native): don't flag P0_TRANSFORMS pages as uncovered server routes#2436
fix(native): don't flag P0_TRANSFORMS pages as uncovered server routes#2436innolope-dev wants to merge 1 commit into
Conversation
The anti-rot scan only consulted ITEMS_TO_DISABLE, so a page whose server-only exports are already stripped by a P0_TRANSFORMS stub still failed the native build. This is live on main: (mobile-ui)/claim/page.tsx has force-dynamic and a matching stub, and the scan rejects it. Skip files handled by a transform, and cover the scan with a unit test.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 10 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ 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 |
Code-analysis diffPainscore total: 6206.68 → 6206.68 (0) |
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
kushagrasarathe
left a comment
There was a problem hiding this comment.
Approved. Root-cause fix — P0_TRANSFORMS files were falsely flagged as uncovered server routes, blocking native build on main. Verified rel/t.path share the same shape; negative-control test guards against an always-true predicate. Non-blocking: full pnpm native:build not run (author flagged), acceptable since main is already stuck at this scan.
The bug — native builds fail on
maintodaydetectUncoveredServerRoutes()inscripts/native-build.jsfails the native build when it finds App Router files with server-only exports. But the script also maintainsP0_TRANSFORMS— files it replaces with static-export-safe client stubs beforenext buildruns. Their server-only exports never reach the export, yet the scan flags them anyway, because it only consultsITEMS_TO_DISABLE:This is not hypothetical. On
mainright now,src/app/(mobile-ui)/claim/page.tsxhasexport const dynamic = 'force-dynamic'(line 11) and a matchingP0_TRANSFORMSentry (native-build.js:86). Someone did the right thing — added the directive and the stub — and the anti-rot guard rejects it anyway. The native build cannot get past this scan.The fix
Teach the scan that transformed files are already handled:
Why this isn't a silent no-op
The obvious failure mode is a predicate that never matches — the scan keeps passing, the "fix" looks fine, and the guard still rejects real routes. Both halves were checked:
relandP0_TRANSFORMS[].pathare the same shape.relispath.relative(APP_DIR, full); the transform loop consumesitem.pathaspath.join(APP_DIR, item.path). Both are relative tosrc/app.(mobile-ui)/claim/page.tsx (export const dynamic = 'force-dynamic'); patched → zero offenders.'src/app/' + normalized) fails 3 of the 4 tests, so they aren't vacuous.api/foo/route.ts,(mobile-ui)/claim/layout.tsx,'') correctly do not match, guarding against an always-true predicate.Tests
scripts/__tests__/native-build-scan.test.js— 4 tests, green under the existing jest config. Plain CJS to match the plain-.jsscript under test.pnpm-lock.yamluntouched.Not verified
A full
pnpm native:buildwas not run — it's a 10–30 min native toolchain build and was deliberately skipped. What's proven is the guard logic itself, not thatnext buildsubsequently completes with the stubs in place. Note that this is already unknown onmain, where the build stops at this scan; the change can only get it further, not less far.