Stringent

const schema = { values: { password: "string", confirmPassword: "string" } } as const;
const values = { values: { password: "hunter2", confirmPassword: "hunter2" } };

const result = parser.evaluate("values.password == values.confirmPassword", schema, values);
const result: boolean

Hover the code above. Every type on this page is real — produced by the actual library, at documentation build time, from a grammar you define.

One grammar. Two engines.

You declare each rule once — as data. The same declaration drives a type-level parser that checks string literals in your code, and a runtime parser that checks strings from users and config files.

Compile time — string literals

Result types are inferred through the grammar — the same overloaded + yields number or string depending on its operands, and expressions that don’t parse don’t compile:

const seven = parser.evaluate("1+2*3", {}, {});
const seven: number

const greeting = parser.evaluate("'Hello '+name", { name: "string" }, { name: "Ada" });
const greeting: string

const label = parser.evaluate("1==2 ? 'yes' : 'no'", {}, {});
const label: string

// ...and an expression that doesn't parse doesn't compile:
parser.parse("1+'a'", {});
Error ts(2345)  ― Argument of type '"1+'a'"' is not assignable to parameter of type 'never'.

Runtime — dynamic strings

The same grammar parses untrusted input with safeParse(), which never throws — you get an error code, an exact position, and what would have been valid there. These are the engine’s real error objects:

parser.safeParse("price * quantitty", { price: "number", quantity: "number" });
// {
//   code: "TYPE_MISMATCH",
//   message: "Expected a number expression at position 8, got unknown ('quantitty' is not in the schema)",
//   position: 8,
//   expected: ["number"],
//   found: "\"quantitty\"",
// }

parser.safeParse("price *", schema);
// { code: "PARSE_ERROR", position: 7,
//   message: "Expected 'true' or 'false', identifier, number or string at position 7, found end of input" }

parser.safeParse("price * 2 oops", schema);
// { code: "UNEXPECTED_INPUT", position: 10,
//   message: "Unexpected input at position 10: found \"oops\" (expected \"*\", \"+\" or \"==\")" }

Parse once, evaluate as often as you like:

const result = parser.safeParse(userInput, schema);
if (result.success) {
  const value = parser.evaluateAst(result.ast, values);
}

Compile-time validation

parse() only accepts string literals that fully parse against your grammar. An invalid expression — a syntax error or an operand type mismatch — is a compile-time error, and valid expressions get an exactly inferred AST and result type. safeParse() even catches schema typos at the offending leaf.

Runtime safety

Dynamic strings go through safeParse(), which never throws for input. You get structured errors with an error code, a 0-based position, and the tokens that would have been valid there.

Polymorphic grammars

Constraints are arktype definitions and matching is assignability. Union constraints, binding references (operand("left"), rest(overlapping("left"))) and derived result types (resultType: "left") give you overloaded operators without per-type node variants — one add node handles number + number → number and string + string → string.

Rules as Standard Schemas

parser.compile() turns a rule into a real arktype Type — a boolean rule becomes a validating predicate with field-attributed ArkErrors, so it drops straight into react-hook-form, tRPC, or hono.

Secure by default

Expressions are treated as untrusted input. All identifier and path lookups are own-property only — __proto__, constructor and friends never resolve to prototype internals, at parse time or eval time.

Dive in

Getting startedInstall stringent and build the quickstart grammar — every example hover-able.

PlaygroundType expressions against a live grammar and watch them parse, type-check, and evaluate.

ArchitectureThe dual-engine design and the one law that makes it work: semantics are data.

API referenceGenerated from the source on every build — always in sync with the published types.

Pre-1.0

The API is stabilizing but may still change between minor versions. See the architecture page for the design and its rationale.