mjst — More JSON Schema Tools

mjst is a monorepo of JSON Schema (Draft 2020-12) tooling for TypeScript. At its core are code generators that turn a schema into:

Around the generators sits a wider toolbox:

• API layer — @amritk/api turns route contracts into typed handlers, request/response validation, an OpenAPI 3.2 document, and a typed client
• Linting — mjst lint checks JSON/YAML documents against JSON Schema and custom style rules, with exact line:column findings
• Adapters — consume schemas authored in TypeBox, Zod, Valibot, Effect, or Apache Avro (.avsc) as input
• $ref resolution — resolve and inline JSON Schema / OpenAPI $refs, with a default-deny SSRF guard
• Runtime validation — fast validation for schemas you don't know ahead of time
• YAML parsing — a tiny, dependency-free YAML parser that keeps exact source positions

The CLI (mjst) is the primary entry point; everything above is also published as a standalone package — see Packages below.

Most tools in this space pick a single lane — types or validation or docs. mjst generates the whole TypeScript surface from one schema, and it can also consume schemas authored in other libraries as input.

_{✅ first-class · 🟡 partial · — not offered}

_{¹ These libraries are a schema source rather than a competitor — mjst consumes them via @amritk/adapters.}

_{² fast-check arbitraries for property testing plus concrete example values, via @amritk/generate-examples.}

mjst's validators are generated TypeScript — straight-line, monomorphic code with no generic dispatch. The exported validateX runs a tiny inlined boolean guard on the happy path and falls back to a separate error-collecting function only when input is actually invalid. On JavaScriptCore that beats every other library measured, the build-time transformer typia included. On V8 it still leads on the object schemas — the shapes an application actually validates — but TypeBox's compiled checker takes the assert-loose moltar shape outright and draws level on assert-strict, so both engines get a row rather than one standing in for the other. The numbers below compare a generated mjst validator against typia, an Ajv-compiled function, a TypeBox-compiled checker, and a hand-written Zod schema on the same data.

Each schema also generates a boolean type-guard isX(input): input is X — a single flat predicate (no error array, no cold-path call) returning the same verdict as validateX. It is the inline-friendly equivalent of TypeBox's compiled check / typia's is, for the common "is this valid?" question where you don't need the error list; validateX remains the rich, error-collecting form.

Steady-state throughput (valid input, higher is better). Each cell is the median of three runs of the whole suite; typia is Bun-only because its checks come from a compile-time transform delivered as a Bun preload:

The assert-loose / assert-strict rows use the same shape as moltar/typescript-runtime-type-benchmarks — they are not that project's numbers, and they are not comparable with its leaderboard. The shape is shared; the harness is not, and the harness is worth an order of magnitude. Every operation on the leaderboard goes through benny (benchmark.js) into a class-property call, around a single frozen module-level fixture whose verdict is discarded. Running the same generated functions under that harness (bun run bench:moltar, one run on Linux x64, Bun 1.4.0 / Node 26.8.1):

The no-op row is a "validator" that checks nothing, so it is the fastest number that harness can produce: on Node the assert-loose figure lands within 12% of it, which is a measurement of benny, not of validation — the leaderboard's ceiling, not any library's, and on CI hardware that ceiling sits lower still. The harness also reorders the field: under benny on Node the generated validator leads TypeBox (~80M against ~54M), the reverse of what our own harness reports on the same functions and the same engine. And moltar's fixture is Object.freeze({ … }), which under Bun 1.3 cost every library about 100× on assert-strict (the Bun cell read ~2.4M); Bun 1.4.0 has closed that cliff (details and the frozen-input benchmark: Frozen inputs).

Frozen inputs are their own workload — on older Bun. Enforcing additionalProperties: false means proving no undeclared key is there, and every library does that by enumerating keys. On JavaScriptCore under Bun 1.3, making an object non-extensible (Object.freeze, Object.seal, Object.preventExtensions) disabled the engine's cached own-keys fast path, so every key sweep — Object.keys, for...in, Reflect.ownKeys — dropped to a generic walk. Property reads were unaffected; only strict schemas paid. Bun 1.4.0 no longer shows the cliff: frozen and mutable input run at the same speed for every library. Frozen config objects and frozen fixtures are ordinary inputs, so the bench keeps measuring them (assert-strict (frozen), small (4 fields, frozen)), and the table carries both runtimes on the same machine:

On Bun 1.3 everything converged because everything was paying the same engine slow path; V8 never had the cliff — the Node columns above are flat, frozen or not — and Bun 1.4 has closed it. Frozen inputs has the alternatives that were measured and why the generated code keeps the key count.

Prepare-a-validator cost (one-shot, lower is better):

_{Measured on Bun 1.4.0 and Node 26.8.1 (Linux x64, a 4-vCPU cloud box — every table in this repo comes from the same machine and runtimes), each cell the median of three runs. Absolutes drift between sittings on that box: the same suite, same commit, read ~60% faster an hour later across every case at once, so the ratios are the durable part. Each library is timed in an isolated process over a pool of distinct inputs, reporting the median of many trials (so the optimiser can't hoist or eliminate the work). Every library agrees on each valid/invalid verdict — parity is asserted before timing — and TypeBox is given uuid/email format checkers so every library does the same work. Reproduce with cd packages/generate-validators && bun run bench.}

Parsing replicates both parse modes of the same benchmark — its modes and its shapes, under this repo's harness rather than the leaderboard's, with the same caveat as above — over the libraries with a pure (non-mutating) parse operation. parseSafe asserts the types and strips undeclared keys (zod's .strip()); parseStrict asserts the types and rejects undeclared keys (zod's .strict()):

_{mjst parses in strict mode throughout (throwing on a type mismatch like the others), adding stripUnknown for parseSafe and additionalProperties: false for parseStrict; zod uses .object/.strictObject and TypeBox a Clean+Assert/Assert pipeline. Parity — identical parsed output, and rejection of every wrong-typed (and, in strict mode, extra-keyed) sample — is asserted before timing. ajv (removeAdditional) and typia (assertPrune) are excluded because they strip by mutating the input in place rather than returning a new value, which a reused input pool can't measure fairly. Reproduce with cd packages/generate-parsers && bun run bench (Bun) or bun run bench:node (Node). Unlike the validator table, the generated parser leads every case on both engines. ³ A strip parse of four declared keys builds one small object and nothing else, which is fast enough that the engine's inlining rather than the parser sets the number — read those cells as ratios.}

No install required — run it directly with your favourite package runner:

# npm
npx @amritk/mjst --schema ./schema.json --out-dir ./generated

# pnpm
pnpm dlx @amritk/mjst --schema ./schema.json --out-dir ./generated

# yarn
yarn dlx @amritk/mjst --schema ./schema.json --out-dir ./generated

# bun
bunx @amritk/mjst --schema ./schema.json --out-dir ./generated

Or use a config file:

npx @amritk/mjst --config ./mjst.config.json

npm install --save-dev @amritk/mjst   # or pnpm add -D / yarn add -D / bun add -d

See the CLI README for the full flag reference and config file examples.

Using mjst from a coding agent (Cursor, Claude Code, Copilot, …)? mjst is pre-alpha, so it isn't in any model's training data — these docs are written to close that gap:

• llms.txt — a curated, link-rich index of every package (llmstxt.org convention), for agents and docs crawlers.
• llms-full.txt — every package's AI.md in one file, to paste straight into a model's context.
• packages/*/AI.md — per package: the mental model, a minimal runnable example, and the gotchas most likely to trip up an LLM. Each also ships inside the published npm tarball, so an agent can read it from node_modules.
• AGENTS.md — for agents editing this repo (build/test workflow, per-package invariants).

Both llms.txt files are generated from the packages by bun run generate-llms, so they stay in sync with the source.

• Node.js ≥ 20 (or Bun) to run the CLI
• TypeScript ≥ 5 in your consuming project

Contributing? You'll need Bun — the repo pins 1.4 via packageManager — it's the package manager and bundler for this repo. See CONTRIBUTING.md.

bun install
bun run test        # run the test suite
bun run check       # lint with biome
bun run build       # build all publishable packages

See .claude/architecture.md for monorepo layout and design notes, and CONTRIBUTING.md for contribution guidelines.

MIT