Hello. There have been issues related to next major Laravel release (so called 7.0), and this is one of them.
Description
Currently, Laravel sorts migrations by date, prepended to migration's filename. For a small project that's an easy solution, allowing us to use artisan make:migration without any hassle. However, when third-party packages come in place, it all leads to naming/renaming files manually as 2000_01_01_000001_whatever_name_here.php to keep the order correct while not loosing the readability. As the project grows, some may choose to use a modular structure. To keep things looking good, you would have to develop own naming scheme to not mess up when creating migrations in yet another module. Unfortunately, people rarely follow such things as they may seem unimportant, so in best case scenario you'll have a bunch of randomly named migrations that somehow work.
Possible solution
What I propose is to make migrations work exactly the same way as seeders. There would be a main "Migrator" coming in laravel/laravel repo that can register migrations in any order developer wants. Migrations classes would no longer be under global namespace and files would be named accordingly.
Pros
No more magic of converting snake_case into class names
No need of scanning directory(ies) to find migrations, autoloading takes place
Better control of migrations flow
Namespacing
Filename is no longer responsible for migrations order
Third-party packages that provide migrations could now let you choose if you want to vendor:publish them or not
Life of modular projects becomes easier
Cons
Breaking change, requiring new major Laravel release
Harder for beginners
I'd like to hear your feedback on this. I may have missed something important, but I'm open for a discussion.
Hello. There have been issues related to next major Laravel release (so called 7.0), and this is one of them.
Description
Currently, Laravel sorts migrations by date, prepended to migration's filename. For a small project that's an easy solution, allowing us to use
artisan make:migration
without any hassle. However, when third-party packages come in place, it all leads to naming/renaming files manually as2000_01_01_000001_whatever_name_here.php
to keep the order correct while not loosing the readability. As the project grows, some may choose to use a modular structure. To keep things looking good, you would have to develop own naming scheme to not mess up when creating migrations in yet another module. Unfortunately, people rarely follow such things as they may seem unimportant, so in best case scenario you'll have a bunch of randomly named migrations that somehow work.Possible solution
What I propose is to make migrations work exactly the same way as seeders. There would be a main "Migrator" coming in laravel/laravel repo that can register migrations in any order developer wants. Migrations classes would no longer be under global namespace and files would be named accordingly.
Pros
Cons
I'd like to hear your feedback on this. I may have missed something important, but I'm open for a discussion.
Thanks regardless.