Convert migration overwrite to a new migration. Resolve Issue #162

[dotancohen]

No description provided.

[dotancohen]

The test seems to be failing because the build process has changed. Previously, it was forbidden to run the initial migration before installing Jetstream. With this change, it is required to run the initial migration before installing Jetstream.

@taylorotwell Can this build process be changed? I don't see where I can contribute to that.

[taylorotwell]

This change isn't really necessary. You can just php artisan migrate:fresh if you run your migrations before installing Jetstream.

[dotancohen]

@taylorotwell Thank you. Though your are correct about the existence of a workaround, that adds burden to the developer. I'll be honest, In three years of Laravel I've never had to use migrate:fresh and it seemed, still seems, like a workaround for when problems arise. This issue is an example of a problem that doesn't have to exist.

In fact, the idea that prior migration files could be overwritten seems completely backwards. Why have migrations instead of a canonical CREATE TABLE definition, if they are just going to be overwritten anyway?

From a prior bug and a discussion online it seems to me that a significant part of the community of Laravel coders agree that migrations should not be overwritten. Of course I defer to your experience but do bear in mind that many of Laravel's target audience, us developers, would like to see this change implemented. Thank you!

[nabeelio]

In fact, the idea that prior migration files could be overwritten seems completely backwards. Why have migrations instead of a canonical CREATE TABLE definition, if they are just going to be overwritten anyway?

Yeah this seems brittle. If you're distributing something and you modify the original migration files, do your originals get overwritten? Or if it's an in-prod app that's being migrated? Is that what could happen here?

[driesvints]

You'll need to create a new migration. Jetstream is meant to be used with new applications. We cannot know what kind of migrations or table modifications you've already done on your users table so you'll need to figure out which changes you need yourself if you want to install jetstream on an existing app.

[dotancohen]

We cannot know what kind of migrations or table modifications you've already done on your users table

If that is the reason, then overwriting the 2014_10_12_000000_create_users_table.php file is doubly backwards. You are establishing that Laravel packages can overwrite extant migration files if they are "meant to be used with new applications". What happens when the dev installs two such packages? One of them will get it's overwriting migration file overwritten!

The purpose of having migrations is to prevent these issues. Whoever authors it does not need to know what other modifications have been made to the table. Declare the fields required and move on.

[driesvints]

Hey @dotancohen. I think you're right about overwriting the migration. Perhaps we can do better and throw a warning to the user? Can you maybe send in a PR for that?

[dotancohen]

@driesvints
Sure, no problem. How would you like it to warn? I'm thinking if the users table already exists, just throw an exception.

[driesvints]

@dotancohen I think we'd also have to take in mind the behavior of --force to skip the warning. Instead of an exception I'd recommend using $this->warn(. Maybe a question to confirm overwriting?

[dotancohen]

@driesvints Sure, no problem. Thank you.

Just to clarify, if --force is used, then drop the current table and install the new table.

[driesvints]

Yeah, force should overwrite any "decisions" that need to be taken.