New Standard, Who Dis?

I made a bet early on: if I wanted OpenPKG to be adopted, I should build on existing standards. JSON Schema (2020-12) for type representation. Not something custom.

That bet paid off faster than I expected.

The trigger was working with Zod and other schema libraries. Static analysis could extract the basic types — string, number, object — but missed everything that made those schemas useful. An email field? Just string. An age with min/max bounds? Just number. The constraints existed only at runtime.

So I started building plugins. Manual adapters for popular schema libraries — Zod, Valibot, ArkType, TypeBox — to extract constraints and merge them into the spec. It worked, but it was brittle. Every library update could break it. I hated the idea of maintaining it.

Then Standard JSON Schema shipped.

The problem, visualized

Take a typical Zod schema:

import { z } from 'zod';

export const UserSchema = z.object({
  email: z.string().email(),
  age: z.number().min(18).max(120),
  username: z.string().min(3).max(20),
});

Static analysis extracts the basic shape:

{
  "schema": {
    "properties": {
      "email": { "type": "string" },
      "age": { "type": "number" },
      "username": { "type": "string" }
    },
    "required": ["email", "age", "username"]
  }
}

The shape is right. But the constraints — email format, min/max values, length limits — exist only at runtime. Static analysis can't see them.

Runtime introspection calls the schema directly and extracts the actual constraints:

{
  "schema": {
    "properties": {
      "email": { "type": "string", "format": "email" },
      "age": { "type": "number", "minimum": 18, "maximum": 120 },
      "username": { "type": "string", "minLength": 3, "maxLength": 20 }
    },
    "required": ["email", "age", "username"],
    "additionalProperties": false
  }
}

Email format. Numeric ranges. Length constraints. additionalProperties: false. Everything a developer — or an LLM — needs to understand how to actually use the code.

The spec

Standard JSON Schema gives validation libraries a common interface for runtime introspection. Any compatible library can expose its constraints as JSON Schema:

const jsonSchema = schema['~standard'].jsonSchema.output({
  target: 'draft-2020-12'
});

One interface. Every library. No adapters.

Using it

Detect if a package uses a Standard JSON Schema-compatible library, run with --runtime, and get the full picture:

# Static only (fast, no execution)
npx @openpkg-ts/cli snapshot src/index.ts

# With runtime introspection
npx @openpkg-ts/cli snapshot src/index.ts --runtime

openpkg detects available TypeScript runtimes (bun, tsx, Node 22+), executes the entry file, finds Standard JSON Schema-compatible exports, and merges the runtime schemas with static analysis.

The lesson

Standard JSON Schema shipped in late 2025. openpkg had already chosen JSON Schema as its output format. When the spec dropped, integration was straightforward — the output format already matched.

Pick a standard. When the ecosystem catches up, you're ready.