Skip to main content
A schema can carry any number of generator blocks, one per SDK you want to emit. A monorepo with a TypeScript API, a Go payments service, and a Python analytics worker generates all three clients from the same file, so every service publishes against the same event definitions.
repost/schema.repost

​
One run, every generator

repost schema generate runs every generator in the schema, in source order. There is no per-generator flag on the CLI; the schema is generated as a unit. repost schema migrate dev does the same as part of recording a migration. The write is transactional across all outputs. Every generator’s tree is staged first, then committed together; if any output fails to write, the already-written ones are rolled back. A generate either updates every client or none of them, so two services can never end up on different versions of the schema after one run. Concurrent runs against the same tree are refused rather than raced. Every output also receives an identical schemas.json, the JSON Schema catalog for your event types. The migration history is language-neutral: one lineage, one set of versions, shared by every generator.

​
Output rules

  • Every output path is resolved relative to the schema file, and each generator needs its own distinct directory. Two generators writing to the same path is a schema error.
  • TypeScript is the only language with a default output (node_modules/.repost/client). One TypeScript generator may use the default; any others need explicit paths.
  • Two generators can share a language. A schema with two TypeScript generators writes byte-identical packages to both outputs.
  • Go and Python require an output. Java and Kotlin additionally require resourceOutput and packageName, as covered in their generation pages.
Each output directory is engine-owned. The generator marks its trees with a marker file, refuses to write into a non-empty directory it doesn’t recognize as its own, and replaces the whole tree on regeneration. Don’t hand-edit or add files inside an output.

​
What gets committed

The default TypeScript output lives in node_modules and stays out of your repo; a postinstall script regenerates it after installs. Every other output, including a TypeScript generator with an explicit path, is committed like any other generated code, and its diff shows up in review alongside the migration that caused it.

​
CI

Two checks keep a polyglot repo honest:
--check recomputes every generator’s output and exits non-zero on drift, listing the changed and stale files per output. Run both on every pull request.

​
JVM builds generate their own subset

The Maven and Gradle plugins select generators by name — <generators><generator>javaSdk</generator></generators> in Maven, repostSdk.generators in Gradle — and process only JVM generators. In a schema that mixes javaSdk with typescript and go, the JVM build regenerates only its own client, and repost schema generate handles the rest. The two paths are complementary and never overlap. repost schema init scaffolds a single generator; a polyglot schema grows by adding further generator blocks to it by hand. repost schema languages lists what’s available.

​
Continue

Defining events

The generator block and everything else in the schema language.

Migrations & deploys

The one migration history all these generators share.

SDKs

The five language guides these generators feed.