prisma-nestjs-graphql: generating NestJS GraphQL types from a Prisma schema

What it generates, and what it deliberately does not

The project generates object types, inputs, args and similar artefacts from a Prisma schema file for use with the @nestjs/graphql module. The feature list has three entries and the third is the important one. It generates only the necessary imports. It combines a zoo of nested and nullable filters. And it does not generate resolvers, since those are application specific. That last constraint is the design, not an omission. Resolvers are where your business logic lives, and a generator that emitted them would be generating the wrong thing. So the division is: Prisma owns the data model, the generator owns the GraphQL type layer, and you own the resolvers. It also explains why the options are all about type shape rather than about endpoints.

Installing it and wiring the generator into your schema

The package is a dev dependency, and it needs the Prisma generator helper and the identity-type library alongside it.

npm install --save-dev prisma-nestjs-graphql @prisma/generator-helper identity-type

Then you add a generator section to your schema.prisma file.

generator nestgraphql {
  provider = "prisma-nestjs-graphql"
  // Or explicit node execution
  provider = "node node_modules/prisma-nestjs-graphql/bin.mjs"
  output = "../src/@generated"
}

The provider line has two forms, the plain package name and an explicit node execution of the binary, which is what you need when the generator is not resolvable by name alone. The output directory is where the generated TypeScript lands, and the README notes that a relative path is resolved against the schema file.

The config file move, and how the old keys still work

The generator options can be defined in a JavaScript config file instead of in the schema, and the README presents this as the preferred style because it gives better readability, validation and IDE autocompletion. You create prisma/nestgraphql.config.mjs and point the generator at it.

generator nestgraphql {
  provider = "prisma-nestjs-graphql"
  configFile = "./nestgraphql.config.mjs"
}

The config file itself is a plain module with a type annotation and an export.

// prisma/nestgraphql.config.mjs
/**
 * @type {import('prisma-nestjs-graphql').ExternalConfig}
 */
export default {
  output: '../src/@generated',
};

The difference shows up in how you express decorators. The old flat style used flattened keys directly in the schema, such as a fields validator entry and a series of decorate entries with a numeric prefix, a from, a name and an arguments list. The new style uses structured objects, with a fields object holding a Validator entry and a decorators array of match functions. The match function receives the object name and property name, so you can target one specific field, and each decorator entry carries from, name, arguments and a namedImport flag. The old keys still work if no configFile is specified, and options from the config file take precedence, so the old style is not dead but mixing the two is the obvious way to get a surprise.

The options that change what your GraphQL schema looks like

The option list is where the real behaviour lives, and a few entries are worth knowing before you generate anything. combineScalarFilters defaults to true and combines nested and nullable scalar filters into a single one, which keeps the input types from multiplying. noAtomicOperations defaults to true and removes the input types for atomic operations, which is the difference between having one where-input per operation or not. emitBlocks selects which families of output to emit, with args, inputs, outputs, models and enums as the possible values and all five as the default, and the README warns that some blocks depend on others, so you cannot emit models without enums. emitSingle merges everything into one file, and emitCompiled emits JavaScript and definitions instead of TypeScript sources. There are also narrower switches, such as typeListNullable adding a nullable marker to relation list properties, omitModelsCount dropping the _count field, and reExport controlling whether an index file is created, with None, Directories, Single and All as the values.

Two options that trade GraphQL correctness against Prisma compatibility

The last two options in the list are the ones that can change how your Prisma types and your generated classes relate to each other, and the README is explicit about the cost. requireSingleFieldsInWhereUniqueInput marks a single field in a where-unique input as required in TypeScript and not nullable in GraphQL, and the note says it will break compatibility between Prisma types and generated classes. unsafeCompatibleWhereUniqueInput sets the TypeScript property type as non-optional for all fields in the where-unique input classes, with issue 177 referenced. Both default to false, which is the safe setting, and both exist because GraphQL and Prisma disagree about whether a unique lookup with one field can be optional. If you turn them on, the generated classes stop matching what Prisma's own types say, and you will find the mismatch at the type checker rather than at the GraphQL layer.

Running it, the scalar packages, and the shape of the repository

Generation is the standard Prisma command.

npx prisma generate

If your models use the Decimal and Json types, the README says you need two extra packages, and gives the command.

npm install graphql-type-json prisma-graphql-type-decimal

Or you can write your own GraphQL scalar types, with a pointer to the NestJS documentation on scalars. The repository layout shows a project with its own generated output checked in, since there is an @generated directory alongside the src, plus an example directory containing an app module, a main file and user and dummy folders, a prisma directory with a config file, a Taskfile for the build, a docker-compose file for a Postgres service, a release config, and a vitest config. The package manifest shows the test script chaining eslint, a type check and the vitest run, and the build going through a Taskfile target for microbundle 6. The licence in the manifest is MIT, the recent releases are on the 23.x line, and the last push was on 2026-10-17.

Editorial conclusion

prisma-nestjs-graphql fits a NestJS team that keeps its data model in Prisma and wants the GraphQL layer generated rather than hand-written, and that has more than a couple of models so the duplication is worth automating. It does not fit a project with a handful of types, where writing them by hand is cheaper, and it does not fit a team that wants the generator to produce resolvers. Verify first which blocks you actually need, since emitting all of args, inputs, outputs, models and enums is more code than a small API needs, and decide early whether to use the new config file or the old flat schema keys, because the old ones still work and mixing them is where precedence surprises come from.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. unlight/prisma-nestjs-graphql on GitHub