The Problem

Clients need a validation engine that runs in Node, the browser, and Deno without pulling in external dependencies. Existing libraries (e.g., Joi) trade speed for feature‑richness, which can become a bottleneck in high‑throughput services or edge‑runtime environments.

What This Does

fastest-validator compiles a JSON‑style schema into a plain JavaScript function using the Function constructor. The compiled checker validates an object in a single pass and returns either true or an array of error objects. The core lives in lib/validator.js, which loads built‑in rule implementations from lib/rules/*.js and message templates from lib/messages.js. Helper utilities such as lib/helpers/deep-extend.js and lib/helpers/flatten.js support rule compilation and error formatting. Example usage is provided in examples/index.js and the browser bundle in examples/browser/index.html.

How It Is Wired

Execution starts when a consumer calls new Validator() (exported from index.js). The constructor forwards to lib/validator.js, the hub module (27 inbound, 27 outbound imports, instability 0.5).

  1. Schema compile – Validator.prototype.compile invokes compile → getRuleFromSchema (8 callers) → compileRule (4 callers) → rule‑specific generators in lib/rules/*.js.
  2. Rule generation – each rule may call deepExtend (5 callers) and makeError (7 callers) to merge defaults and produce error objects.
  3. Validation – the generated checker calls check (the main validation loop) which ultimately invokes render → check → rule functions. makeError is the most frequently called error builder (48 call sites).

The call graph shows no circular dependencies, but lib/validator.js is a high‑impact hub; any change there propagates to all rule modules and the public API. The deepest nesting (7 levels) appears in lib/validator.js and several object‑rule tests, making those files cognitively heavy. Several test files (test/integration.spec.js, test/typescript/integration.spec.ts, test/validator.spec.js) exceed 1 200 lines, inflating the blast radius for test‑maintenance.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/fastest-validator
cd fastest-validator

# Install dependencies
npm ci

# Run the benchmark (optional sanity check)
npm run bench

# Compile a schema in your code
node -e "
const Validator = require('./index');
const v = new Validator();
const schema = { id:{type:'number',positive:true,integer:true}, name:{type:'string',min:3} };
const check = v.compile(schema);
console.log(check({id:5,name:'Bob'})); // true
"

No additional configuration files are required; the library is zero‑dependency and works out‑of‑the‑box in Node, browsers (via the UMD bundle in examples/browser/index.html), and Deno (examples/deno/index.ts).

Real‑World Use

A microservice handling millions of JSON payloads per second can instantiate a single Validator per schema at startup, cache the compiled checker, and invoke it for each request. Because the checker is plain JavaScript, V8 can inline and optimize it, delivering the advertised ~8 M validations / s on modest hardware.

Code Health & Issues

  • High – Pin third‑party GitHub Actions to a commit SHA (.github/workflows/deno.yml uses denolib/setup-deno@master).
  • Medium – Declare least‑privilege permissions for GITHUB_TOKEN (.github/workflows/deno.yml).
  • Medium – Enable Dependabot or Renovate (package.json present, no config).
  • Medium – Add a dependency‑vulnerability scan to CI (.github/workflows lacks such a step).
  • Medium – Set persist-credentials: false on the checkout step (.github/workflows/nodejs.yml).
  • Low – Define timeout-minutes on workflow jobs (.github/workflows/nodejs.yml).

The repository includes full test coverage, a permissive MIT license, and CI for Node. No Dockerfile, secret leakage, or missing documentation beyond the README and basic examples.

The Bottom Line

fastest-validator delivers a genuinely dependency‑free, high‑throughput validation engine with a clear entry point and well‑scoped rule modules. Maintenance complexity stems from a dense core (lib/validator.js) and oversized test files; addressing those hotspots would ease future changes. Suitable for performance‑critical Node, browser, or Deno projects that can tolerate a modestly complex core.