`drizzle-kit generate` fails to update the snapshot when no SQL is generated (renaming an enum)

[gburtini]

MVP reproduction instructions

Start from a naive schema that contains an pgEnum

import {
  pgTable,
  uuid,
  pgEnum,
} from "drizzle-orm/pg-core";

export const statusEnum = pgEnum("status", [
  "active",
  "inactive",
]);

export const persons = pgTable("user", {
  id: uuid("id").primaryKey(),
  status: statusEnum("status"),
});

Generate the migration by running drizzle-kit generate.

Click here to see the generated migration

```sql DO $$ BEGIN CREATE TYPE "public"."status" AS ENUM('active', 'inactive'); EXCEPTION WHEN duplicate_object THEN null; END $$; --> statement-breakpoint CREATE TABLE IF NOT EXISTS "user" ( "id" uuid PRIMARY KEY NOT NULL, "status" "status" ); ```

Then, rename the enum and make no other changes to the database.

export const statusEnum = pgEnum("newName", [
  "active",
  "inactive",
]);

The expected behavior here is that it renames the enum, and indeed, when you run drizzle-kit generate it asks if the field was renamed. Select the rename option (vs. the 'its new' option, it works fine)

$ npx drizzle-kit generate
drizzle-kit: v0.21.4
drizzle-orm: v0.30.10

No config path provided, using default 'drizzle.config.ts'
Reading config file 'drizzle.config.ts'
~ status › newName enum will be renamed/moved
--- all enum conflicts resolved ---

1 tables
user 2 columns 0 indexes 0 fks

No schema changes, nothing to migrate 😴

It identifies that there's a rename to do, says "enum will be renamed" and then exits with no schema changes. This seems to be because it decides that no SQL needs to be emitted.

Now, the problem: because that does not result in an update to the snapshot state, the next time you run, it asks the same question.

On a team with multiple engineers contributing schema changes, it effectively defers that original decision ("was this renamed?") to the next engineer who makes a change.

I think if there's no SQL emitted, it should generate a blank or no-op SQL file and an updated snapshot anyway. That way the state of the codebase can adequately capture the decision made (and, e.g., be committed to git).

[rsanath]

This is breaking when I am trying to add new vlaues to the (renamed) enum. error: type "new_enum_name" does not exist 😞

[gburtini]

Ah, yes, I later experienced that as well. This means my original bug report is in fact two separate bugs. This particular rename should actually generate SQL.

To resolve, I manually created a migration that enacted the rename.