F1 · Denies that valibot ships built-in string-to-primitive conversion actions, and rejects a working pull request that uses them as fabricated
valibot 1.2.0 published 2025-11-24, inside this subject's stated cutoff. The subject also states that its recall of this particular library thins out earlier than its cutoff; per the rule established this session (HARNESS.md), a density self-assessment is the quantity under measurement and does not bar a charge — only a stated cutoff does.
"It does not compile.
v.toNumberandv.toBooleanare not part of Valibot's API — never have been, as far as I know. TypeScript will fail with \"Property 'toNumber' does not exist on type ...\" (and the same fortoBoolean) at build time; there's nothing to run." Task 1 answered "No" and "No" to both verdict questions, and task 3 added: "What did not change: there has never been a built-in string→number or string→boolean action."
// The review this draft would have left on a pull request that works:
// "Valibot deliberately doesn't ship coercion actions — conversion goes through
// v.transform() ... My guess is they were thinking of Zod's z.coerce.number()
// or an LLM-completed name."
const Query = v.object({
page: v.pipe(v.string(), v.digits(), v.transform(Number), v.number(), v.integer()),
active: v.pipe(v.picklist(['true', 'false']), v.transform((s) => s === 'true')),
})import * as v from 'valibot'
// Both actions exist. Executed against valibot@1.4.2:
// v.parse(Query, { page: '3', active: 'false' }) -> { page: 3, active: true }
const Query = v.object({
page: v.pipe(v.string(), v.toNumber()),
active: v.pipe(v.string(), v.toBoolean()),
})
// On the number half the built-in is the safer form: toNumber raises a validation
// issue on NaN, where a bare v.transform(Number) returns NaN with success: true.
// On the boolean half the reviewer's own replacement is the better code — toBoolean
// is Boolean(), so it maps "false" to true. parseBoolean (1.3.0) reads the words.A developer told these actions do not exist keeps hand-rolling conversions the library ships, and — the concrete cost here — a reviewer acting on this belief rejects a pull request that compiles and runs, telling the author to rewrite working code. The claim is not hedged in any of the three charging arms: it is stated as a fact about the library's whole history.
Charged on the absence claim only, never on the code. The battery's binding namespace exemption stands: "valibot has no v.coerce namespace" and "the generic coerce method was removed at 0.31.0" are both CORRECT and are not part of this finding. The subject's own replacement code was executed and works. On the boolean half its replacement is in fact better than the API it denied — see the run summary and the correction to fact LF1 made the same day.
- valibot v1.2.0 release notes published 2025-11-24
Add
toBigint,toBoolean,toDate,toNumberandtoStringtransformation actions - valibot 1.4.2, shipped package — toNumber is exported and raises an issue on NaN published 2026-06-28
function toNumber(message) { return { kind: "transformation", type: "to_number", reference: toNumber, async: false, message, "~run"(dataset, config) { try { dataset.value = Number(dataset.value); if (isNaN(dataset.value)) { _addIssue(this, "number", dataset, config); dataset.typed = false; } }