Managing Duplicate Laravel Migration Files Generated by Cursor + Composer

I’m using Cursor + Composer with Laravel.

With Laravel, you create database migration files to define the schema of your database.

You typically create these with a CLI command (“PHP artisan make:migration xyz”), which will produce a correctly named but pretty empty file. Part of the naming convention is to prefix the name with a timestamp (eg. 2024_09_21_12345_create_some_table.php)

From there, as a developer, you would populate the file with your DB table schema eg:

    public function up(): void
    {
        Schema::create('groups', function (Blueprint $table) {
            $table->id();
            $table->string('name')->unique();
            $table->timestamps();
        });
    }

From there, you run php artisan migrate and the database tables will be created in line with the definitions of these files.

When doing this within Cursor: from my description, Composer infers (mostly) correctly the database requirements of an app, and will then provide the commands for creating the file (php artisan make:migration xyz), but will also create migration files itself, but with a name like:

xxxx_xx_xx_create_some_table.php

So then I will have somewhat duplicate files:

  • 2024_09_21_12345_create_some_table.php (which is mostly empty/placeholder) and
  • xxxx_xx_xx_create_some_table.php (which contains the schema definition).

At this point, I then copy/paste the contents of the Cursor-generated file into the one generated by php artisan make:migration (and delete the Cursor-generated file) - or - I rename the Cursor-generated file to that of the file created by the command (and delete the php artisan generated file).

When we’re handling one file at a time, it’s not so bad, but sometimes 5+ files can be created simultaneously and sometimes when other migration files already exist in the project - this becomes quite tricky to manage.

I would love for Cursor Composer to:

1.	Provide the necessary php artisan commands.
2.	Wait for my confirmation that I’ve run them.
3.	Then modify the newly created files accordingly.

I tried requesting this behavior in my prompt. Cursor paused after providing the commands, but when I instructed it to continue, it created more xxxx_xx_xx type files instead of modifying the existing ones.

Any thoughts on how I can improve this workflow? Thanks in advance for your help!

I’m having the same issue. It’s very frustrating. There are several migrations that Cursor named 2024 instead of 2025, and I didn’t notice the discrepancy until several migrations later. Plus, ones with arbitrary names or were almost exact dupes of previous ones. The result of this is that all the migrations need to be unwound. Cursor tries to run all the migrations over again, but since some are out of order, it causes issues. Ideally, I’d like to change this behavior in .cursorrules, but I have not been able to make it follow these attempts. I came here looking to find someone who has solved this issue.