The migration `20210501202953_name_of_previous_migration` was modified after it was applied

Bug description

When I try to run migrations after changes in the schema file, I am getting almos always an error message: The migration ... was modified after it was applied.

I can continue but I will loose all data after confirming resetting the database.

How to reproduce

I am using Blitz.js with Prisma, so the command looks a bit different.

I change the shema.prisma file. Then I run migration dev with prisma cli tool in PowerShell

blitz prisma migrate dev --create-only

And I have the same issue, with: npx prisma migrate dev

Expected behavior

The migration files should be created with no warnings and without suggesting to reset the database. Without this message: We need to reset the PostgreSQL database

Prisma information

The change I made in a model.

model Event {
  id                   Int                    @id @default(autoincrement())
  createdAt            DateTime               @default(now())
  updatedAt            DateTime               @updatedAt
  title                String
  titleShort           String?

.....

+ private              Boolean                @default(true)
  published            Boolean                @default(false)

....
}

Environment & setup

• OS: Windows, PowerShell
• Database: PostgreSQL 12
• Node.js version: v15.8.0 (I think I hade same issues with v14.x)
• Prisma version: windows / 2.21.2

prisma               : 2.21.2
@prisma/client       : 2.21.2
Current platform     : windows
Query Engine         : query-engine e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules\prisma\node_modules\@prisma\engines\query-engine-windows.exe)
Migration Engine     : migration-engine-cli e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules\prisma\node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine : introspection-core e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules\prisma\node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary        : prisma-fmt e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules\prisma\node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash : e421996c87d5f3c8f7eeadd502d4ad402c89464d
Studio               : 0.371.0
Preview Features     : orderByRelation

[kivi]

Hi @pantharshit00,

sorry can not share content of my migrations directory.

I almost sure it is the checksum, that is saved in migrations table that differs after committing oder pulling from repository. Line breaks result in CR/LF by saving of a text file on Windows. Depending on Git settings, line breaks can be transformed to LF.

I think a pragmatic approach could be that the file get’s created with LF only. And Prisma might adds an .gitattribures file with

* text=auto eol=lf
*.{png,jpg,jpeg,gif,webp,woff,woff2} binary

More details about gitattributes: https://www.aleksandrhovhannisyan.com/blog/crlf-vs-lf-normalizing-line-endings-in-git/#autocrlf-true

Here is how could be reproduced:

Change git config autocrlf to autocrlf=true. Make sure you made this change to be able to reproduce with git config list

1. change schema.prisma
2. prisma migrate dev --create-only
3. check the eol of file, I see LF
4. commit on a test branch
5. delete the file
6. and checkout again
7. check eol of file, I see CRLF

Now you can run migrate again or you can guess the checksum of the file has changed and therefore we will get the the error … was modiefied …

Suggestion

Why I suggesting a pragmatic solution? I guess most Users are using a modern tool like vsCode and they can handle LF as good as CRLF. But I have set autocrlf based on some documentations about Formatting and Whitespaces: https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

So prompting to add .gitattributes with that fix while running prisma migrate for Windows users could prevent this errors or at least this should be documented.

[randolphpark]

thanks @kivi. It saved me massive time.

I used dos2unix prisma/<../migrationfile.sql> fixed the file. With LF eol, it is happy with migration.