Uh oh!
There was an error while loading. Please reload this page.
perf: keep valibot out of production client bundles - #869
Conversation
Two runtime call sites forced the valibot schema runtime into every production client bundle, worth 12 KB raw (3.7 KB gzip) on the basic fixture. - `speedcurve.ts` derived `LUX_USER_CONFIG_KEYS` from `SpeedCurveOptions.entries` at module scope, which pinned the schema past the `import.meta.dev` guard. The keys are now listed, with type assertions that fail to compile if they drift from the schema. - `_gcm-consent.ts` validated consent state with `safeParse` on a strict schema. It now uses a hand written check with the same warnings. Every other registry schema was already dev only and treeshakes.
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Warning Review limit reached
Next review available in:16 minutes Limit details: You’ve used all 4 included reviews currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
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 |
commit: |
📦 Package Size📚 23 runtime dependencies (no change)
All tracked output (28)
Runtime dependencies (23)
Baseline: main_@_151a94b9___2026-08-18 · gzip is the comparison metric · changes below 16 B gzip are ignored |
Uh oh!
There was an error while loading. Please reload this page.
📚 Description
Every registry schema is meant to be dev only.
schema: import.meta.dev ? XOptions : undefinedis the pattern, and it treeshakes correctly. Two call sites broke it, so valibot's schema runtime shipped to the browser on every page: a 12 KB chunk, 3.7 KB gzipped, on the basic fixture.The first is the one I did not expect.
speedcurve.tsbuilt its LUX passthrough list at module scope:That reads the schema at runtime, so the schema survives the dev guard and drags valibot in with it. The keys are listed literally now. Deriving them was there to stop the list drifting from the schema, so the type checker does that job instead:
Add a key to
SpeedCurveOptionsand forget the list, and typecheck fails.The second is
_gcm-consent.ts, which ransafeParseagainst a strict rebuild ofgcmConsentStateon everyconsent.default()andconsent.update()call. That is real runtime validation, so no guard would have helped. It is a hand written check now, same warnings, plus the same style of compile time guard againstConsentStategrowing a key.Client bundle on
test/fixtures/basicgoes 576 KB to 568 KB, and the valibot chunk is gone.I only measured the basic fixture. A build using SpeedCurve or GCM consent heavily should improve by at least as much, but I have not measured one.