go get -tool github.com/JacobLey/leyman/apps/genever/go/cmd/genever@v0.1.0

It reads the same schemas, has the same strict mode, and rejects the same bad schemas with the same kind of error at the same JSON Pointer. It writes Go structs instead of TypeScript types. Two of genever's dependencies came along, because the Go command has to sign its output and keep a manifest the way the TypeScript one does: populate-files and generated-signature are Go modules now too, released at the same version.

This continues a pattern in my adoption of Go, which forces language-agnostic support for common functionality (in this case, type-ifying JSON Schema + OpenAPI).

None of the Go code is tested against the TypeScript code. Both are tested against a set of test vectors: inputs and expected outputs, as JSON, that the TypeScript implementation computed once and that are committed to the repository.

One directory per package, one per language

Each of these packages is a directory named after the package, with one project per language beside the vectors they share:

apps/genever/
├── README.md        what every implementation promises
├── ts/              published to npm as genever
├── go/              the Go module github.com/JacobLey/leyman/apps/genever/go
└── test-vectors/    schemas, sample values and error cases, as JSON

populate-files and generated-signature have the same shape. constant-consistent-hash, the oldest of the four, has ts/, go/, rust/, and a wasm/ package that calls the Rust implementation from TypeScript.

Until the release, the TypeScript package was the root and the Go code lived in a go-impl/ folder next to it. Moving each language into its own directory means neither is the package. The group README describes what holds in every language (the format a file is signed in, which schemas are rejected and where), and a third language has an obvious place to go.

Where the expected values come from

genever's vectors are a TypeScript package that writes JSON files under out/ on every build:

• 45 schema fixtures, each with sample values it accepts. The schemas are Juniper definitions and the samples come from juniper-arbitrary with a fixed seed, so a file only changes when a fixture does.
• Two OpenAPI documents, 3.0.3 and 3.1.0, with samples of each component.
• errors.json: 74 schemas genever rejects, each with the kind of error and the JSON Pointer it must name.

The files are committed, and CI fails if one is stale. The TypeScript genever runs the vectors from the package; the Go one reads the JSON by relative path:

func testVectors() fs.FS {
	return os.DirFS(filepath.Join("..", "test-vectors"))
}

Reading by path was a late change. The vectors started as a Go module that embedded the JSON, which works until you release: a published Go module can't require one that isn't published, and the vectors are only for tests. So the Go tests read the working copy, and the Go project lists the vectors in its Nx implicitDependencies so its tests rerun when they change (commit).

generated-signature has 187 cases in one file (signing, verifying, manual sections, manifests), and populate-files has 71 scenarios: files written, hand edits made, then one call with the results, error and files it must leave behind.

No implementation regenerates the values it is tested against: if the Go port could rewrite them, a change in Go would update the vectors and pass.

The same error, at the same pointer

genever's error cases are vectors too. One per kind, from errors.json:

{
    "invalid": {
        "type is unknown": { "schema": { "type": "date" }, "pointer": "#/type" }
    },
    "strict": {
        "unknown keyword": { "schema": { "type": "string", "foo": 1 }, "pointer": "#/foo" }
    },
    "unsupported": {
        "$dynamicRef": { "options": { "strict": false }, "schema": { "$dynamicRef": "#node" }, "pointer": "#/$dynamicRef" }
    }
}

The Go test checks the error's kind with errors.Is and its pointer, and that each strict mode case is accepted once strict mode is off:

var geneverErr *genever.Error
if !errors.Is(err, kind) || !errors.As(err, &geneverErr) || geneverErr.Pointer != item.Pointer {
	t.Fatalf("got %v, expected %s at %s", err, kind, item.Pointer)
}

Moving the cases out of the TypeScript tests made those tests stricter too. They had checked the error's class but not the pointer. And the whole suite had run as OpenAPI 3.0, which hid that one check (exclusiveMaximum) behaved differently outside it; now only the two cases that need OpenAPI 3.0 run as it (commit).

What the vectors caught

generated-signature's vectors cover the places where Go and JavaScript disagree by default: what JavaScript's \s and trim() count as whitespace, Node.js's extname, lowercase İ, the byte order mark TextDecoder drops, and JSON.stringify's escaping. One case lists five manifest keys, Z, a, é, 😀 and ￿, in that order. JavaScript compares strings by UTF-16 code unit, so the emoji (a surrogate pair starting at 0xD83D) sorts before ￿. Go compares UTF-8 bytes, where ￿ comes first. A manifest written by one would look edited to the other, so the Go code sorts by utf16.Encode.

In populate-files, the TypeScript package was the one that changed. The Go port decided every file before writing any, so a refused write left everything as it was. The TypeScript package wrote files in parallel as it decided them, so a refusal could come after other files were written. The scenarios couldn't pin the files a failed call leaves while the two disagreed, so the TypeScript package changed to match the port in populate-files 1.2.3 (commit), and the scenarios now pin those files.

A third turned up the day before release. The released modules declare go 1.24, the oldest Go they support, and CI now runs each released module's tests on Go 1.24 as well as the current Go. That run failed: Go 1.24's JSON decoder reports an unclosed { or [ only when asked for the closing delimiter, which genever-go's order-keeping JSON parser had been discarding, so truncated JSON was accepted. It now fails with ErrSyntax (commit).

Where vectors stop

The vectors say which schemas are accepted and which values every generated type must hold. They can't say how narrow a Go type is, since Go has no union or literal types and a json.RawMessage field would hold every sample. So the Go tests also read each fixture's generated declarations back with go/types and compare them with what's expected: struct fields and their types, union variants, enum constants. A fixture without expectations fails, so a new one can't go unchecked. Neither implementation's tests compare generated text, so formatting can change freely.

For how genever-go compares with other Go generators, the Go comparison runs it, go-jsonschema and oapi-codegen through the same probes every night: 18 values decoded into the type generated from a JSON Schema, and 7 into the type for an OpenAPI request body. I wrote genever-go, and only its results are tested.

In the run of November 11, 2026:

go-jsonschema's type doesn't keep null apart from an absent property, can't hold null as a member of a mixed enum, and decodes three values it should reject: a tuple with a string member, a oneOf branch with a property of the wrong type, and a patternProperties value of the wrong type. oapi-codegen's type decodes the tuple with a string member and doesn't keep null apart from absent in a mixed enum. Before kin-openapi 0.152.0, oapi-codegen's loader rejected the 3.1 document, so it scored 0 / 7.

Try it

go get -tool github.com/JacobLey/leyman/apps/genever/go/cmd/genever@v0.1.0

//go:generate go tool genever openapi.yaml --package api --signed
package api

It needs Go 1.24 or later, as does the code it writes. The released modules keep replace directives pointing at each other's workspace copies, so a change to populate-files is tested against genever before either is tagged. go install refuses a module with replace directives, which is why the install line uses go get -tool: it ignores a dependency's replaces and pins the version in your go.mod.

The Go guide covers the options and how Go types differ from the TypeScript ones. If a schema is accepted by one implementation and rejected by the other, that's a bug in one of them, and the test vectors are where the fix starts.

My existing package, Juniper, avoids this by building the schema in TypeScript at runtime, so its types come straight from the code. That leaves a gap: a schema from somewhere else, like another service's OpenAPI spec or a shared JSON file, can't be safely pulled into TypeScript that way.

I wrote genever for those schemas. It reads the file and writes types narrow enough that the bad data above is a compile error. To check that it really is narrower than the alternatives, and stays that way, a nightly job gives it and five other generators the same schema and type-checks what each one produces.

The same schema, two outputs

A schema for an order, with one property per feature that TypeScript can express but most generators don't:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id": { "type": "string", "pattern": "^ord_" },
    "location": {
      "type": "array",
      "prefixItems": [{ "type": "number" }, { "type": "number" }],
      "items": false,
      "minItems": 2
    },
    "shipping": {
      "oneOf": [
        {
          "type": "object",
          "properties": { "kind": { "const": "pickup" }, "store": { "type": "string" } },
          "required": ["kind", "store"],
          "additionalProperties": false
        },
        {
          "type": "object",
          "properties": { "kind": { "const": "delivery" }, "address": { "type": "string" } },
          "required": ["kind", "address"],
          "additionalProperties": false
        }
      ]
    },
    "headers": {
      "type": "object",
      "patternProperties": { "^x-": { "type": "string" } },
      "additionalProperties": false
    },
    "payment": {
      "type": "object",
      "properties": { "card": { "type": "string" }, "billingAddress": { "type": "string" } },
      "dependentRequired": { "card": ["billingAddress"] },
      "additionalProperties": false
    }
  },
  "required": ["id"],
  "additionalProperties": false
}

json-schema-to-typescript 16.0.0, the most-downloaded tool that writes a .ts file from JSON Schema, generates this (banner comment removed):

export interface Order {
  id: string;
  /**
   * @minItems 2
   */
  location?: never[];
  shipping?:
    | {
        kind: "pickup";
        store: string;
      }
    | {
        kind: "delivery";
        address: string;
      };
  headers?: {
    /**
     * This interface was referenced by `undefined`'s JSON-Schema definition
     * via the `patternProperty` "^x-".
     */
    [k: string]: string;
  };
  payment?: {
    card?: string;
    billingAddress?: string;
  };
}

The oneOf union is right. location is never[], so even a valid [1, 2] fails to compile (2020-12's prefixItems isn't read). id and headers take any string, and payment allows a card without a billing address.

npx genever order.json --name Order writes:

export type Order = {
    /**
     * @pattern "^ord_"
     */
    id: `ord_${string}`;
    /**
     * @minItems 2
     */
    location?: [number, number];
    shipping?:
        | {
              kind: 'pickup';
              store: string;
          }
        | {
              kind: 'delivery';
              address: string;
          };
    headers?: {
        [key: `x-${string}`]: string;
    };
    payment?: {
        card?: string;
        billingAddress?: string;
    } & (
        | {
              card?: never;
          }
        | {
              billingAddress: string;
          }
    );
};

Each of those mistakes is now a compile error:

const wrongId: Order = { id: 'usr_1' };
const wrongLocation: Order = { id: 'ord_1', location: [1, 2, 3] };
const wrongHeader: Order = { id: 'ord_1', headers: { accept: 'json' } };
const noBillingAddress: Order = { id: 'ord_1', payment: { card: '4242' } };

How the comparison works

One schema proves nothing, so the comparison runs every night in CI. Every tool gets the same documents: one JSON Schema with a property per feature (nullable values, mixed enums, tuples, oneOf objects, recursion, closed patternProperties, literal patterns and dependentRequired), and an OpenAPI 3.1 document for the tools that read OpenAPI.

Each probe is one line of TypeScript, compiled against the generated type:

• accepts: a value the schema allows must type-check.
• rejects: a value the schema forbids must not type-check.
• reads: reading a value must give exactly the right type, compared with an identity check, so any doesn't pass.

Most comparisons only check that valid values are accepted, which any wide enough type does; any passes all of them. The rejecting probes are the ones that separate the tools.

I wrote the probes too, so of course genever passes them. Each one follows what the spec says a validator must accept or reject, and the documents and probes are public; if one is unfair to a tool, or a feature is missing, open an issue.

json-schema-to-ts and TypeBox infer types inside TypeScript instead of writing a file, so they get the schema pasted in as const. That is their best case. Import the same schema from a .json file and TypeScript widens it; json-schema-to-ts then gives unknown.

What the latest run found

Results from the 2026-11-06 run, 23 JSON Schema probes each:

On the OpenAPI document, genever passed 10 of 10 probes and openapi-typescript 7.13.0 passed 9, missing only the literal pattern.

The other rows are a snapshot: what each tool did that night, at the version shown. When one of them ships a fix, the next run picks it up. Only genever's results are asserted by the comparison's tests.

Generating from a schema of 500 definitions took genever 54 ms, json-schema-to-typescript 141 ms and quicktype 295 ms (median of 5 runs, on a shared CI runner, so only compare within one run). The tools that infer types aren't timed, since their cost is paid while type-checking.

The live report on genever's docs is rebuilt from each night's run, with the failed probes on hover.

Where I'd use the others

If the same schema feeds Go, Swift or Kotlin code, use quicktype: it generates for many languages and can infer a schema from sample JSON, and genever only writes TypeScript. If you want runtime checks and the schema has no $refs, json-schema-to-zod gives you a Zod validator with the type attached, one generated file instead of a type plus a separate validator. json-schema-to-ts and TypeBox have no build step, which matters when the schema is already written in TypeScript; if it is, Juniper is my version of that, with the same types genever generates. And openapi-typescript has more built around it, openapi-fetch for one; genever's Paths and Operations types are shaped like its output.

Run it yourself

The comparison is a package in the repository, and the nightly job runs it with Dagger, so a clone, Docker and the Dagger CLI are enough to run the same thing:

git clone https://github.com/JacobLey/leyman.git && cd leyman
dagger call comparison-report --commit="$(git rev-parse HEAD)" export --path ./reports

The report is reports/genever.json, beside the Go comparison's.

Versions are pinned in the lockfile, so running the same commit gives the same versions as the table.

Try it

npx genever schema.json --name MyType

Commit the output, and run genever --ci in CI to fail when it's out of date. Getting started covers the rest, including OpenAPI documents and references to other files.

A type doesn't check anything at runtime. minLength, format and most patterns have no TypeScript equivalent, so data still needs a validator: Ajv or juniper-validator.