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:

• 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, or Effect 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, so a valid-input check matches or beats every other library measured — running clear of the build-time transformer typia on most shapes and neck-and-neck with it on the flat assert-loose case. 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):

The assert-loose / assert-strict rows are the exact shape used by moltar/typescript-runtime-type-benchmarks.

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

_{Measured on Bun 1.3 (Linux x64); micro-benchmark figures vary by machine and runtime. 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 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.}

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

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

# pnpm
pnpx @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 ≥ 1.1) to run the CLI
• TypeScript ≥ 5 in your consuming project

Contributing? You'll need Bun ≥ 1.1 — 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