| name | upgrade-validator |
| description | Upgrades the npm `validator` dependency and syncs express-validator chain types, implementations, options, and `declarations/validator.d.ts` with validator.js releases. Express-validator intentionally pins `validator` to patch-only semver (see PR |
upgrade-validator
Policy: why upgrades are manual
This project does not float on arbitrary new minor lines of validatorjs/validator.js. As described in express-validator#1253, the validator dependency is pinned to patch (e.g. ~x.y.z) so a new minor from upstream cannot be pulled in implicitly and surface mistaken or unexpected breaking changes. Bumping validator is a deliberate maintainers’ task: run this workflow, sync types and chain APIs, test, and ship.
After npm install, keep package.json consistent with that policy (typically ~<resolved-version>, not a loose ^ on the major/minor line unless the project explicitly changes policy).
Before you start
- Record the previous
validator version from package.json (and confirm after upgrade from package.json / lockfile).
- The source of truth for what changed is validatorjs/validator.js. Use a tag range compare (e.g.
v<old>...v<new>) to see commits and the diff between versions.
1. Upgrade the package
From the repo root, install the latest validator in-range and persist it to package.json / the lockfile:
npm install validator@latest
If npm rewrites the range to ^ and the project uses patch-only pinning per #1253, change the dependency to ~<version> to match the previous convention.
2. Map upstream changes to this codebase
For each new validator, sanitizer, or option type introduced between the old and new version (use the GitHub compare / changelog, not only commit titles):
New validator (check API)
src/chain/validators.ts: under // validator's validators, add the new method signature in alphabetical order with the rest. Follow existing JSDoc style for adjacent methods.src/chain/validators-impl.ts: under // Standard validators, add the implementation in alphabetical order, delegating with addStandardValidation(validator.<name>, ...) the same way sibling methods do. If upstream uses custom logic (see e.g. isAlpha, toArray-style), match the existing pattern in that file.
New sanitizer
src/chain/sanitizers.ts: under // validator's sanitizers, add the method in alphabetical order.src/chain/sanitizers-impl.ts: under // Standard sanitizers, add the implementation in alphabetical order (addStandardSanitization vs customSanitizer as appropriate).
New options / types
src/options.ts: add or extend types only when the new value is:
- enum-like (e.g. a new locale, a new UUID version constant), or
- an object (e.g.
{ min, max }, or other structured options).
- Skip
options.ts for parameters that are only a plain string or number with no new shared option shape—use inline types on the chain method if needed, consistent with nearby code.
Everything else
- Upstream internal or non–type-surface changes that do not add or change validator/sanitizer signatures need no express-validator edits beyond the version bump and declaration sync (if any).
3. Declarations
- Update
declarations/validator.d.ts: new export function entries must stay in alphabetical order and match the installed validator call signatures. Reuse import('../src/options').<Type> for option types the same way existing declarations do.
4. Verify
From the repo root:
npm test
npm run lint
npm run docs:regenerate-api
Fix any failures before finishing.
Quick reference — section markers
| File | Section comment |
|---|
src/chain/validators.ts | // validator's validators |
src/chain/validators-impl.ts | // Standard validators |
src/chain/sanitizers.ts | // validator's sanitizers |
src/chain/sanitizers-impl.ts | // Standard sanitizers |
