supabase/postgres-meta

Generate const array of possible enum values

gwax opened this issue · 8 comments

gwax commented

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I would like to have values matching possible enum values that are synchronized to the database schema for looping or use with zod and similar tools.

Describe the solution you'd like
A clear and concise description of what you want to happen.

for a schema:

export type Database = {
  public: {
    Enums: {
      mytype: "value" | "other"
    }
  }
}

I would like to have generated values:

export const DatabaseValues = {
  public: {
    Enums: {
      mytype: ["value", "other"],
    },
  },
} as const;

this would allow defining zod types to match like:

const mySchema = z.object({
  mytype: z.enum(DatabaseValues.public.Enums.mytype),
});

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

  • manually keeping values in sync with the database and hoping they don't fall out of sync
  • writing custom type checkers to ensure that values match the schema

Additional context
Add any other context or screenshots about the feature request here.

Sorry for the late reply on this. I believe we are currently generating typescript enums. Is it not sufficient to zod schema?

No, you are generating unions of string literals, which is a different thing. The current types that are generated can only be used for static type-checking (unlike proper Typescript enums.)

gwax commented

@sweatybridge , could you please reopen this feature request

As @toBeOfUse notes, the code does not generate typescript enums (which are values), it generates string literal unions (which are types). (export type vs export const)

The types generated currently are removed by the typescript compiler and cannot be used at runtime.

Generated values are useful both for the zod case and for iterating over values.

A workaround is present in #864

Reopened this gauge interest on generating values in addition to types.

This is a kind of a duplicate of #864 now

#901 looks good to me

gwax commented

@soedirgo , #901 does this