Can you rename migration files to your own custom format?

Yes, you can name them however you want, but they will run in alphabetical order (which is why laravel timestamps them). Also you can change a migrations name after the fact (you've already run the migration). You just need to change the filename in the migrations database table (so it can find it to roll it back) in addition to changing the actual filename and classname.

I'd use a 3 digit number for the prefix. (001_migrationname) to leave enough room for future migrations. You never know.

@CRONIX - That's what I planned was three digits. I know you can update the db with the new file name, I just wanted to make sure that Laravel wasn't parsing the front of the file name for any reason.

Thanks!

No problem. One thing to keep in mind is when you do it that way, it gets hard to create a migration that should be run between 2 other existing migrations since there isn't any room for additions if you use 001_migrationName, 002_migrationName, etc, and you end up having to rename a lot of things. That's a typical scenario you come across in dev (obviously you wouldn't add migrations in between other migrations on a production box.) With the timestamps used, that's pretty easy since they aren't sequential, but are still chronological, so you can insert many new migrations in between existing.

Hm, yeah you're right. Maybe instead of 001, I could just do intervals of 10, and then in between move tables around. I wish it were easier than just renaming files, like some kind of migration config file or something, but that's a little much, Laravel likes to keep things simple. I just hate the migration file names with timestamps, too much to look at.

I hear you, but I think if you just power through that thought, your life will be simpler and you'll code faster. It drove me nuts for awhile early on too, and after coming up with my own migration naming scheme, it was just easier to use artisan make:migration and go with it rather than run it, rename the files, sometimes forgetting to increment by 10 instead of 1, etc. It just wastes time in the end. Once I just accepted it, things were just easier lol.

I'd have to agree with you, if ordering the execution of migrations by filename is the way Laravel wants to do it, then the best way is going to be a long timestamp on the file name.

I ended up posting an idea on Github about it. A lot of people don't understand that I'm talking about changing migrations before production after a code refactor.

Apparently a lot of people are cramming all of their Schema::create() statements for creating tables into single migration files, which does not seem to be the recommended approach given the way Laravel's packages build migrations. Migrations files are created per model being added.

Thanks for the input, a lot of people just don't understand changing a migration before the application is launched. It happens. Refactoring, normalization, and generally just feature changes before launch always happen.

https://github.com/laravel/ideas/issues/1482