prisma: Client should contain `Enum` even if not used by a model
Bug description
Enum declared in the prisma.schema
, but not used for any model field, is created in the migration but not in the client index.d.ts
.
I want to use the prisma.schema
as the source of truth and map my GraphQL codegen config to point to the generated Prisma enums.
How to reproduce (all in https://github.com/okomarov/prisma)
Clone this repo, cd to the /enum_not_generated
and then run:
docker compose up -d
after that you create a migration:
yarn prisma migrate dev -n 'Add enum'
and verify that it contains:
-- CreateEnum
CREATE TYPE "Color" AS ENUM ('RED', 'BLUE');
So it correctly detects the enum. Then generate the Prisma client:
yarn prisma generate
and check that prisma/output/index.d.ts
does NOT contain:
export const Color: {
RED: 'RED',
BLUE: 'BLUE'
};
This ‘enum’ will be added if we add it e.g. to our Dummy
model like so:
model Dummy {
id String @id @db.Uuid
color Color
}
Expected behavior
Prisma generates the enum in the client’s index.d.ts
regardless wether it’s used by a model.
Prisma information
generator client {
provider = "prisma-client-js"
output = "./output"
}
datasource db {
provider = "postgresql"
url = env("DB_URL")
}
model Dummy {
id String @id @db.Uuid
}
enum Color {
RED
BLUE
}
Environment & setup
- OS: MacOS
- Database: PostgreSQL 14
- Node.js version: v16.14.0
Prisma Version
prisma : 3.14.0
@prisma/client : 3.14.0
Current platform : darwin-arm64
Query Engine (Node-API) : libquery-engine 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine : migration-engine-cli 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine : introspection-core 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary : prisma-fmt 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Default Engines Hash : 2b0c12756921c891fec4f68d9444e18c7d5d4a6a
Studio : 0.460.0
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 23
- Comments: 19 (1 by maintainers)
It is DEFINITELY useful to have enums that aren’t included in models.
For example: Say you want an enum consisting of error codes to be defined in
schema.prisma
as your single source of truth, but accessible to your (generated) graphql schema, and in your javascript/typescript (server and client). You probably wouldn’t want a particular error code to be included in any particular model, but you would want the error code enum NOT to be silently removed simply because it happens not to be in any model.I would need this as well, any updates?
Still no updates on this ?
I second this issue. Generating all enums should be easier than the dead code elimination that the generator is doing now.
Any update on this? We are having JSON field as metadata, that uses values from ENUM in prisma model. Looking for ways to have this enums generated in such usecases.
Mentioned this on the Prisma Slack, but I’d also like this for the same reason - especially in a monorepo, having enums defined in two different services can be difficult to maintain when they eventually get used via code generation (for GraphQL in my own case)
We created a custom generator that takes in the model and outputs the “skipped” enum to the client. Super hacky, but gets the job done. I’d far prefer an “includeAllEnums” option on the prisma client generator so it would output them by default.
I liked this better than adding a “fake” table to the database that uses all the extra enums. Might be interesting to do the same thing but with a view so there is nothing generated to the database.
Just wrangled with this for a couple of hours before recognizing the pattern in my schema (not used in model -> not defined in generated prisma client), and now confirming with this thread. As mentioned above, my prisma.schema is my single source of truth for the db. It’s very inconvenient, and unsafe, to maintain separate schemas at various layers.