prisma-trpc-generator turns a Prisma schema into typed tRPC routers

The API layer you owe every new Prisma model

Every model you add to a Prisma schema quietly creates a debt. Someone still has to write the list, get, create, update and delete procedures for it, wire input validation, and keep the shapes honest against the schema. prisma-trpc-generator, a Prisma 2+ generator published by omar-dulaimi, is aimed squarely at that debt. Its stated purpose is to emit fully implemented tRPC routers from your Prisma schema, with Zod validation, middleware and optional tRPC Shield support, and the README frames the goal as turning a schema into production ready tRPC APIs. The audience is backend developers who have already committed to Prisma for the data layer and tRPC for the transport layer. The generator gives complete CRUD coverage for all Prisma operations, and the emitted code is TypeScript, so the intent is type safety across the whole path rather than a runtime shim over loosely typed calls. The trade is that the shape of your API stops being a design decision and becomes a generator output.

How the generator hooks into prisma generate

The wiring is short. You add a generator block to your schema that names the provider and points at an output directory and a JSON config file. Both paths are resolved relative to the schema file, in the same way Prisma resolves generator paths, so with the schema at prisma/schema.prisma the block reads prisma/trpc.config.json and writes to prisma/generated. That placement matters, because the generator then runs inside Prisma's own generate step rather than as a separate watcher or a second command you have to remember. Router code is refreshed whenever you regenerate, which is how the project keeps procedure input types in step with the schema. The dependency list also shapes the output. It includes ts-morph for working with TypeScript source, plus prisma-zod-generator and prisma-trpc-shield-generator, which tells you that the input schema and permission pieces are contributed by those packages rather than being written from scratch in this one. The generated tree contains a schemas directory when Zod is switched on, and the routers wire .input() on each procedure automatically.

Installing the package and running the first generation

The package ships on npm under the name prisma-trpc-generator, and the install step is one line with whichever package manager you already use.

npm install prisma-trpc-generator

The stated requirements are Node.js 20.19.0 or newer, Prisma 7.0.0 or newer and TypeScript 5.4.0 or newer, with the 22.x line of Node recommended. Next, declare the generator inside your schema.

generator trpc {
  provider = "prisma-trpc-generator"
  output   = "./generated"
  config   = "./trpc.config.json"
}

The config file carries the feature switches. A complete one, with every key the project documents, looks like this.

{
  "withZod": true,
  "withMiddleware": true,
  "withShield": "./shield",
  "contextPath": "./context",
  "trpcOptionsPath": "./trpcOptions",
  "dateTimeStrategy": "date",
  "withMeta": false,
  "postman": true,
  "postmanExamples": "skeleton",
  "openapi": true,
  "withRequestId": false,
  "withLogging": false,
  "withServices": false,
  "showModelNameInProcedure": true
}

The config path is resolved relative to the schema file, so the file above lands at prisma/trpc.config.json. The project also asks you to enable strict mode in tsconfig.json, then run the generator.

npx prisma generate

A DATABASE_URL is required, since the generator reads the environment the same way prisma.config.ts does. The example environment file in the repository uses a local SQLite file.

DATABASE_URL=file:./dev.db

The JSON config replaced inline options, and the old way is on borrowed time

Version 2 moved configuration into a single JSON file, and the generator block is now expected to carry only output and config. Two escape hatches remain, and both are worth knowing about. The aliases configPath and configFile are also accepted as names for the config key. Inline options inside the generator block still work when no config file is supplied, but the documentation marks them deprecated and states they will be removed in a future major release. If a config file is present and inline options are also written, the inline values are ignored and a warning is issued. Two defaults are worth planning around. showModelNameInProcedure defaults to true, which yields procedure names such as createOneUser and aggregateUser; setting it to false produces createOne and aggregate, which reads better when the procedures already sit under a per model router. DateTime inputs are governed separately by dateTimeStrategy, where the default value of date accepts only Date objects, coerce accepts both Date objects and ISO strings, and isoString applies ISO string validation with transformation. A client that posts ISO timestamps will be rejected by the default strategy unless you change it or transform the payload yourself.

Where the generated API stops being enough

The failure modes here are not crashes so much as gaps. The generator emits a fixed set of CRUD procedures, and the moment you need a non standard endpoint, a custom query, a filtered list with business rules, or a mutation that spans several models, you are editing generated code or writing a parallel hand built router. That creates the usual awkward fork: a hand written router next to a generated one, with the middleware, the context and the naming conventions to keep in agreement. Configuration also points at files you supply. withShield expects a shield module path, contextPath expects your tRPC context, and trpcOptionsPath expects your tRPC options; a missing or relocated file leaves the generated imports pointing at nothing. Feature coverage is uneven as well. The feature guide labels OpenAPI support as an MVP and offers an optional DDD services layer behind withServices, and both are described as opt in extras rather than finished paths. The repository does not document rollback of a generation run, so there is no stated way to recover the previous output if a regeneration produces something you dislike. There is also no statement anywhere about how generated files should be excluded from review, or whether the output directory is meant to be committed.

How it differs from assembling tRPC routers yourself

The obvious alternative is to write the tRPC router by hand over a PrismaClient, adding zod schemas where you want validation. That path gives you full control over procedure names, argument shapes and response types, and it costs you the repetition: for a schema with many models you write the same list, detail, create, update and delete handlers again and again, and you keep them in sync with the schema by hand. prisma-trpc-generator takes the opposite position. It reads the schema at generate time and produces the procedure set mechanically, then lets you tune naming and validation through the config file. The middle ground is to treat the generated tree as a starting layer that you extend with custom routers rather than replace, and to use the strict flag in tsconfig.json so the compiler catches drift. The generator also leans on sibling packages for the schema and shield halves of the job, so those two concerns arrive in their own shape rather than as one merged design, which matters if you already have an opinion about how your permission rules should read.

Release history and the upgrade cost of a deprecated config style

The repository is not archived and its last push was on 2026-07-28. The recent release list shows v3.1.0 published on 2026-07-28, preceded by v3.0.1 and v3.0.0 both on 2025-11-22, so the visible history moves in bursts rather than on a fixed cadence, and the gap between the 3.0 line and 3.1 is the largest one on record. The package is MIT licensed, which keeps the generated output and the tooling inside the same permissive terms for most projects, though your own legal review should cover how you use it. The practical upgrade cost sits in the config surface. Because inline options are documented as deprecated and slated for removal in a future major release, any project still carrying them will need to move to a JSON config file at some point, and the config key names in the example above are the contract you are signing up for. Two other release notes matter for planning: the generator requires Prisma 7.0.0 or newer, and the package depends on the Prisma 7 generation helper and internals, so a project still on an older Prisma major will find the generator out of step with its own client.

Editorial conclusion

Adopt prisma-trpc-generator if your stack already pairs Prisma with tRPC and you want CRUD procedures generated instead of hand written, and stay on it while you are willing to own a generated tree of TypeScript in your repository. Skip it if you need custom procedure bodies, non CRUD endpoints or a router shape that does not fit the generated layout, since correcting the output by hand costs more than writing the router yourself. Before you commit, run prisma generate once against your real schema and diff the result, and check that every path your config file names, such as contextPath and the shield module, resolves to a file you actually maintain.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. omar-dulaimi/prisma-trpc-generator on GitHub
4. README
5. Releases