Feature Summary

I'd like to be able to @ignore certain values in enums, much like how we can do with fields. This way the enum is left alone in the database, but doesn't show up in the generated code.

Use Cases & Problem Description

Currently, deprecating and renaming values in enums makes migrations very painful.

• The generated migration for Postgres (on Prisma v5.11.0) causes migration errors without manual editing.
• Even value changes have been accounted for, any deletions to an enum value requires dropping the original enum in Postgres. This has caused thread lock issues for large databases.

Proposed Solution

enum SupportedCarType {
  COUPE @ignore
  SEDAN
  VAN
}

The above enum should be in the database, but COUPE should be omitted from the generated code.

Nice to haves

Additional @deprecated directive - When this is used instead of @ignore, it doesn't remove the enum value. It should add a JSDoc @deprecated directive to the generated TypeScript code. This would be picked up by TypeScript Intellisense, making it easier to avoid using the old values without breaking the compile step. That makes change management a lot easier for values that are used very frequently.

Warnings for destructive enum changes - A simple comment in the auto generated migration which suggests the use of the above features whenever an enum change requires the enum to be dropped.

Alternative Solutions

Most of the time we just leave the enums alone, and this results in bloat of deprecated enum values. Adding a comment in the Prisma file helps with documentation, but doesn't prevent the values from showing up in Intellisense or being accidentally used.

Potential Considerations

I'm not sure how useful an @@ignore directive for the whole enum would be.

Prisma Version

5.11.0

What part of Prisma does this affect?

None

Additional Context

No response

Pre-Submission Checklist

• I have searched existing issues to make sure this is not a duplicate
• I have checked the Prisma roadmap to see if this is already planned
• I have described why this belongs in Prisma Core rather than a solution in application code