This project is looking for maintainers.
We are not using this package anymore ourselves, so we can no longer validate/review/test any incoming PRs anymore and ensure correct functionality.
If you are an experienced open source contributor and are interested in taking over maintenance, please open a GitHub issue and let's discuss how to proceed.
Generates ConnectDTO
, CreateDTO
, UpdateDTO
, and Entity
classes for models in your Prisma Schema. This is useful if you want to leverage OpenAPI in your NestJS application - but also helps with GraphQL resources as well). NestJS Swagger requires input parameters in controllers to be described through classes because it leverages TypeScript's emitted metadata and Reflection
to generate models/components for the OpenAPI spec. It does the same for response models/components on your controller methods.
These classes can also be used with the built-in ValidationPipe and Serialization.
npm install --save-dev @vegardit/prisma-generator-nestjs-dto
generator nestjsDto {
provider = "prisma-generator-nestjs-dto"
output = "../src/generated/nestjs-dto"
outputToNestJsResourceStructure = "false"
exportRelationModifierClasses = "true"
reExport = "false"
createDtoPrefix = "Create"
updateDtoPrefix = "Update"
dtoSuffix = "Dto"
entityPrefix = ""
entitySuffix = ""
fileNamingStyle = "camel"
}
All parameters are optional.
output
]: (default: "../src/generated/nestjs-dto"
) - output path relative to your schema.prisma
fileoutputToNestJsResourceStructure
]: (default: "false"
) - writes dto
s and entities
to subfolders aligned with NestJS CRUD generator. Resource module name is derived from lower-cased model name in schema.prisma
exportRelationModifierClasses
]: (default: "true"
) - Should extra classes generated for relationship field operations on DTOs be exported?reExport
]: (default: false
) - Should an index.ts be created for every folder?createDtoPrefix
]: (default: "Create"
) - phrase to prefix every CreateDTO
class withupdateDtoPrefix
]: (default: "Update"
) - phrase to prefix every UpdateDTO
class withdtoSuffix
]: (default: "Dto"
) - phrase to suffix every CreateDTO
and UpdateDTO
class withentityPrefix
]: (default: ""
) - phrase to prefix every Entity
class withentitySuffix
]: (default: ""
) - phrase to suffix every Entity
class withfileNamingStyle
]: (default: "camel"
) - how to name generated files. Valid choices are "camel"
, "pascal"
, "kebab"
and "snake"
.Annotations provide additional information to help this generator understand your intentions. They are applied as tripple slash comments to a field node in your Prisma Schema. You can apply multiple annotations to the same field.
model Post {
/// @DtoCreateOptional
/// @DtoUpdateHidden
createdAt DateTime @default(now())
}
CreateDTO
and UpdateDTO
Entity
CreateDTO
- useful for fields that would otherwise be omitted (e.g. @id
, @updatedAt
)UpdateDTO
- useful for fields that would otherwise be omitted (e.g. @id
, @updatedAt
)Entity
although it's optional in PrismaSchema - useful when you don't want (SQL) ON DELETE CASCADE
behavior - but your logical data schema sees this relation as required
(Note: becomes obsolete once referentialActions are released and stable)CreateDTO
- useful when you want to allow to create related model instancesCreateDTO
- useful when you want/need to connect to an existing related instanceUpdateDTO
- useful when you want to allow to create related model instancesUpdateDTO
- useful when you want/need to connect to an existing related instanceGenerally we read field properties from the DMMF.Field
information provided by @prisma/generator-helper
. Since a few scenarios don't become quite clear from that, we also check for additional annotations (or decorators
) in a field's documentation
(that is anything provided as a tripple slash comments for that field in your prisma.schema
).
Initially, we wanted DTO
classes to implement Prisma.<ModelName><(Create|Update)>Input
but that turned out to conflict with required relation fields.
This kind of DTO represents the structure of input-data to expect from 'outside' (e.g. REST API consumer) when attempting to connect
to a model through a relation field.
A Model
s ConnectDTO
class is composed from a unique'd list of isId
and isUnique
scalar fields. If the ConnectDTO
class has exactly one property, the property is marked as required. If there are more than one properties, all properties are optional (since setting a single one of them is already sufficient for a unique query) - you must however specify at least one property.
ConnectDTO
s are used for relation fields in CreateDTO
s and UpdateDTO
s.
This kind of DTO represents the structure of input-data to expect from 'outside' (e.g. REST API consumer) when attempting to create
a new instance of a Model
.
Typically the requirements for database schema differ from what we want to allow users to do.
As an example (and this is the opinion represented in this generator), we don't think that relation scalar fields should be exposed to users for create
, update
, or delete
activities (btw. TypeScript types generated in PrismaClient exclude these fields as well). If however, your schema defines a required relation, creating an entity of that Model would become quite difficult without the relation data.
In some cases you can derive information regarding related instances from context (e.g. HTTP path on the rest endpoint /api/post/:postid/comment
to create a Comment
with relation to a Post
). For all other cases, we have the
@DtoRelationCanCreateOnCreate
@DtoRelationCanConnectOnCreate
@DtoRelationCanCreateOnUpdate
@DtoRelationCanConnectOnUpdate
annotations that generate corresponding input properties on CreateDTO
and UpdateDTO
(optional or required - depending on the nature of the relation).
When generating a Model
s CreateDTO
class, field that meet any of the following conditions are omitted (order matters):
isReadOnly
OR is annotated with @DtoReadOnly
(Note: this apparently includes relation scalar fields)field.kind === 'object'
) and is not annotated with @DtoRelationCanCreateOnCreate
or @DtoRelationCanConnectOnCreate
@DtoCreateOptional
AND
When generating a Model
s UpdateDTO
class, field that meet any of the following conditions are omitted (order matters):
@DtoUpdateOptional
isReadOnly
OR is annotated with @DtoReadOnly
(Note: this apparently includes relation scalar fields)isId
(id fields are not supposed to be updated by the user)field.kind === 'object'
) and is not annotated with @DtoRelationCanCreateOnUpdate
or @DtoRelationCanConnectOnUpdate
@DtoUpdateOptional
AND
When generating a Model
s Entity
class, only fields annotated with @DtoEntityHidden
are omitted.
All other fields are only manipulated regarding their isRequired
and isNullable
flags.
By default, every scalar field in an entity is required
meaning it doesn't get the TypeScript "optional member flag" ?
next to it's name. Fields that are marked as optional in PrismaSchema are treated as nullable
- meaning their TypeScript type is a union of field.type
and null
(e.g. string | null
).
Relation and relation scalar fields are treated differently. If you don't specifically include
a relation in your query, those fields will not exist in the response.
isRequired = false
)isRequired = true
)@DtoRelationRequired
(do this when you mark a relation as optional in PrismaSchema because you don't want (SQL) ON DELETE CASCADE
behavior - but your logical data schema sees this relation as required)All files are released under the Apache License 2.0.