fix(valibot): upgrade @valibot/to-json-schema to 1.8.0 - #2009
Conversation
1.8.0 allocates `$defs` reference ids per conversion and reserves ids already present in `definitions`, instead of drawing from a module-global counter. That makes generated OpenAPI documents reproducible and stops an anonymous recursive schema from overwriting a supplied definition. Raise `@orpc/valibot`'s `valibot` peer floor to `>=1.5.0` to match the peer requirement 1.8.0 now declares, and prune the `minimumReleaseAgeExclude` entries that have aged past the gate.
More templates
@orpc/ai-sdk
@orpc/arktype
@orpc/bun
@orpc/client
@orpc/cloudflare
@orpc/contract
@orpc/experimental-effect
@orpc/evlog
@orpc/hibernation
@orpc/json-schema
@orpc/experimental-msw
@orpc/nest
@orpc/next
@orpc/node
@orpc/openapi
@orpc/opentelemetry
@orpc/pinia-colada
@orpc/pino
@orpc/publisher
@orpc/ratelimit
@orpc/server
@orpc/shared
@orpc/swr
@orpc/tanstack-query
@orpc/trpc
@orpc/valibot
@orpc/zod
commit: |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
ℹ️ No critical issues — the bump, peer-range adjustment, and lockfile are consistent. One non-blocking suggestion on regression coverage.
Reviewed changes
@valibot/to-json-schema^1.5.0→^1.8.0inpackages/valibot/package.json, with the lockfile importer specifier, integrity/peer block, and snapshot updated in lockstep.valibotpeer>=1.0.0→>=1.5.0, matching the peer@valibot/to-json-schema@1.8.0declares and the package's own^1.5.0devDependency.minimumReleaseAgeExcludepruning inpnpm-workspace.yaml— aged-out entries removed, only@valibot/to-json-schema@1.8.0kept.
I reproduced the upstream behavior against the installed 1.8.0: repeated conversions now return byte-identical output, a supplied definitions entry is no longer clobbered, and v.pipe(v.number(), v.minValue(5), v.minValue(1)) keeps minimum: 5. pnpm vitest run packages/valibot passes (20 tests). The peer bump follows the repo's >= lower-bound convention (zod >=4.5.0, effect >=4.0.0-beta.90) and every workspace valibot pin is ^1.5.0, so nothing else is affected. The rationale for raising the peer floor despite 1.4.x still working is sound — the transitive peer already warns on 1.4.x, so this just makes the advertised range honest.
ℹ️ The reproducibility fix isn't pinned by a test
The PR's headline guarantee — a document regenerated in the same process keeps its component names — is currently only verified by the author's manual runs. Since the dependency is pinned to ^1.8.0, a future 1.8.x/1.9.x minor that reintroduces global $defs allocation would silently regress it. A small test in packages/valibot/src/converter.test.ts that converts the same recursive schema twice and asserts deep equality would lock the behavior in.
Technical details
# Missing regression coverage for reproducible `$defs` allocation
## Affected sites
- packages/valibot/src/converter.test.ts — has no test exercising repeated conversions of the same recursive schema.
## Required outcome
- A test that converts a recursive Valibot schema (with `definitions`) twice via `ValibotToJsonSchemaConverter` and asserts both results are deeply equal, so a dependency regression in the `^1.8.0` range is caught by CI.
## Suggested approach (optional)
- Add to the existing `valibotToJsonSchemaConverter` describe block; no production code change needed.openrouter/deepseek/deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏
1 participant
Upgrades
@valibot/to-json-schemafrom 1.7.1 to 1.8.0. Generated OpenAPI documents are now reproducible: 1.8.0 allocates$defsreference ids per conversion rather than from a module-global counter, so regenerating a document in the same process no longer renames its components. No oRPC source changes were needed;ValibotToJsonSchemaConverteris drop-in compatible.Fixes
components.schemasnamed0,1,2,3, then4,5,6,7on the next call in the same process.definitions: { 0: PlanetSchema }, an anonymous recursive schema claimed$defs/0and replaced Planet, leaving$refs resolving to the wrong schema.v.pipe(v.number(), v.minValue(5), v.minValue(1))previously widened tominimum: 1.Compatibility
@orpc/valibot'svalibotpeer range moves from>=1.0.0to>=1.5.0, matching the peer 1.8.0 declares for itself.This one is worth a reviewer's judgement, because valibot 1.4.x does still work in practice:
@valibot/to-json-schemahas no runtime imports from valibot, and the full suite passes on 1.4.2 with 1.8.0 installed. The bump makes the advertised range deliverable rather than fixing a break. Consumers on 1.4.x already get an unmet-peer warning today from the transitive dependency while the published>=1.0.0claims support, and neither pnpm nor npm hard-fails on it.Housekeeping
Pruned the
minimumReleaseAgeExcludeentries that have aged past the gate, as that list's own comment asks, leaving only the new@valibot/to-json-schema@1.8.0. A fullpnpm installpasses and pnpm re-adds none of them.Testing
pnpm vitest run— 3353 passed, 47 skippedpnpm type:check— cleanpnpm lint— cleanpnpm peers check— no unmet valibot peerBoth fixes were verified by running the same code against 1.7.1 and 1.8.0. A scratch consumer project also confirmed that with the currently published
@orpc/valibot@2.0.0-beta.35, a valibot 1.4.x install already resolves@valibot/to-json-schema@1.8.0and warns once pnpm's release-age gate lapses.Noted separately while reviewing, pre-existing and untouched here: converting a
v.set()orv.map()whose element schema is recursive emits a$defsblock nested underitemswhile the$refto it stays root-absolute, so that reference dangles.