express-validator

express-validator brings the extensive validator.js library of string validators and sanitizers into Express as a fluent, chainable middleware. Instead of hand-rolling if/else checks for every field in req.body, req.query, req.params, req.headers, or req.cookies, you attach a validation chain (e.g. check('email').isEmail().normalizeEmail()) directly to a route, and the library handles field selection — including nested paths and wildcards — validation, sanitization, and error collection for you.

Beyond individual field chains, it offers checkSchema() for declaring validations across many fields as a single object, oneOf() for alternative-field validation logic, and checkExact() to reject requests containing fields nobody validated. An ExpressValidator factory class lets teams register their own named validators and sanitizers with full TypeScript type inference, so custom rules read like built-in chain methods. The result is a mature, widely-used building block for input validation in Express APIs rather than a full framework or a one-off utility.

What You Get

• Chainable per-field validation and sanitization via check(), body(), query(), param(), cookie(), and header()
• A schema-based alternative, checkSchema(), for declaring validations across many fields in one object
• oneOf() for requiring at least one of several alternative validation chains to pass
• checkExact() to reject requests that include fields no chain validated
• matchedData() to extract only the validated/sanitized values into a clean object
• An extensible ExpressValidator class for registering custom, type-safe validators and sanitizers as first-class chain methods

Common Use Cases

• Validating and sanitizing form and JSON payload fields on REST API endpoints
• Normalizing user input (emails, trimming whitespace, escaping HTML) before it hits business logic or storage
• Enforcing that only expected fields are present in a request body via checkExact()
• Building reusable validation chains shared across multiple routes in larger Express applications
• Adding custom domain-specific validators (e.g. checking a value against a database) alongside built-in validator.js rules

Under The Hood

Architecture The public API in src/index.ts and src/express-validator.ts exposes location-scoped chain builders (check, body, query, param, cookie, header) that all funnel through buildCheckFunction() to construct a ValidationChain (src/chain/validation-chain.ts) backed by a Context (src/context.ts) accumulating an ordered stack of ContextItems — standard validations, custom validations, sanitizations, bail conditions, and chain/custom conditions, each in its own file under src/context-items/. Field selection against req.body/query/params/headers/cookies, including dotted paths and wildcard globs, is resolved by src/field-selection.ts and src/context-builder.ts, and a ContextRunner (src/chain/context-runner-impl.ts) executes the stack against the selected field instances as Express middleware. Every Context created for a request is appended to a shared array under a well-known request key, which is how validationResult() and matchedData() later aggregate errors and values across every chain attached to that request without them needing to know about each other.

Tech Stack Written in TypeScript and compiled with tsc, the library has exactly two runtime dependencies: lodash for data grouping/traversal (notably in Context.getData()) and validator for the underlying string validators and sanitizers (isEmail, isURL, escape, etc.) that get wrapped as StandardValidator/StandardSanitizer functions. It has no dependency on Express itself — it is designed to be mounted into any Express-compatible middleware pipeline. Tooling includes ESLint 9’s flat config with eslint-plugin-import and Prettier, Jest 29 with ts-jest for tests, and a separate Docusaurus site under website/ for documentation, published to GitHub Pages after each release.

Code Quality The repo has 22 colocated .spec.ts test files covering the context, chain, context-item, and middleware layers, run via Jest with coverage collection configured to exclude type-only and index files. Internal modules consistently separate a typed interface (validators.ts, context-runner.ts) from its implementation (validators-impl.ts, context-runner-impl.ts), keeping the public surface small while the wiring stays testable in isolation. Linting (ESLint + Prettier) and the test suite both run in CI across six Node.js versions (14 through 24) with coverage submitted to Coveralls on every build, indicating a well-maintained, actively verified codebase.

API Design The chainable syntax (check('email').isEmail().normalizeEmail()) composes validators and sanitizers per field with very little boilerplate, and the location-scoped shortcuts remove the need to specify req.body vs req.query manually. checkSchema() gives a declarative alternative for routes with many fields, while oneOf() and checkExact() cover validation patterns — alternative fields, disallowing unknown fields — that are awkward to hand-roll directly against validator.js. The ExpressValidator factory extends this further, letting teams register custom validators/sanitizers that get full TypeScript inference as chain methods. None of this is conceptually novel for a request-validation library, but the ergonomics and type safety are executed carefully.