At most one validation library
Why it matters
Two validation libraries produce two schema syntaxes, two inferred-type systems, two error-object shapes, and two ways to compose refinements. A backend route validated with Zod cannot share its schema with a frontend form validated by Yup, so every endpoint has its contract defined twice and they drift the moment someone adds a field to only one side. Error rendering components branch on library-specific shapes, and TypeScript type narrowing works on one side but not the other.
Severity rationale
High because schema drift between frontend and backend causes silent validation gaps where invalid data passes one check and fails the other.
Remediation
Standardize on one library — Zod if you want TypeScript-first inference, Yup if you have deep Formik-era code. Colocate every schema in src/lib/schemas/ and import from both client and server code.
// src/lib/schemas/login.ts
import { z } from 'zod'
export const LoginSchema = z.object({
email: z.string().email(),
password: z.string().min(8),
})
export type LoginInput = z.infer<typeof LoginSchema>
Remove the loser with npm uninstall yup @hookform/resolvers.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Multi-Session Drift Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from ai-slop-code-drift·automated