prisma format strips comments on block level attributes

[Joelkang]

Bug description

As it says on the tin: it seems like all block level attribute comments are stripped out when running prisma format

Some tangential, but relevant context: I have the same problem as this issue and solved it by implementing this hack, which uses a specific comment //nomigrate to ignore certain lines (specifically a ts_vector GiST index) prior to running prisma migrate dev.

However I realised that after running prisma format, the comment at my index was gone, causing prisma migrate dev to always generate a migration for my index, and thus causing it to fail since the index was correctly already in the DB.

Not sure if related to this #3658

How to reproduce

run npx prisma format

Expected behavior

Block level attribute comments should not get stripped out on format

Prisma information

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["extendedIndexes"]
}
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL") 
}

model A {
  id          String    @id @default(uuid())  @db.Uuid // this is preserved
  foo String    @db.Uuid // this is preserved
  bar       String // this is preserved
  bat        String?// this is preserved
  baz       String? // this is preserved

  @@map("table_name") // this is removed
  @@unique([foo, bar]) // this is removed
  @@index([bat(ops: raw("gist_trgm_ops"))], type: Gist) // this is removed
  @@index([bar(ops: raw("gist_trgm_ops"))], type: Gist) // this is removed
  @@index([baz]) // this is removed
}

Environment & setup

• OS: MacOS Monterrey 12.3.1
• Database: Postgresql
• Node.js version: v16.14.2
• Using prisma inside of a yarn workspace

Prisma Version

prisma                  : 3.14.0
@prisma/client          : 3.14.0
Current platform        : darwin
Query Engine (Node-API) : libquery-engine 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt 2b0c12756921c891fec4f68d9444e18c7d5d4a6a (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : 2b0c12756921c891fec4f68d9444e18c7d5d4a6a
Studio                  : 0.460.0

[pantharshit00]

Thanks for reporting this. I can confirm this bug.

[tomhoule]

After prisma/prisma-engines#3030, the schema reformats to:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["extendedIndexes"]
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model A {
  id  String  @id @default(uuid()) @db.Uuid // this is preserved
  foo String  @db.Uuid // this is preserved
  bar String // this is preserved
  bat String? // this is preserved
  baz String? // this is preserved

  @@unique([foo, bar]) // this is removed
  @@index([bat(ops: raw("gist_trgm_ops"))], type: Gist) // this is removed
  @@index([bar(ops: raw("gist_trgm_ops"))], type: Gist) // this is removed
  @@index([baz]) // this is removed
  @@map("table_name") // this is removed
}

So I think we can consider the problem fixed. Thanks for reporting this!