Can't provide a path to migrate:rollback

[warrickhill]

if you run php artisan migrate --path=path/to/migrations the migrations run fine but you can't run php artisan migrate:rollback --path=path/to/migrations

The "--path" option does not exist.

[leesleefeng]

Because migrate:rollback is based on the migrations table.
This command undo the latest batch of migrattions, not one.

While there is an alternative.
You can do what you want to undo in a new migration file and run migrate.
Since each migration consists of an up and down methods, rollback means run codes in the down method, then in the new migration file, you just write those codes of the down metod in the up method.

Example:

old migration file:

up method:
$table->integer('for_num'); // add for_num field

down method:
$table->drop('for_num'); // delete field

new migration file:
up mtehod:
$table->drop('for_num');

down mthod of the new file can be left blank and do nothing.

.

[mrk-j]

If you run composer dump-autoload this actually works. I tested this as follows:

• Created a migration in database/migrations/sub/2016_05_20_192337_create_sub_table.php.
• Then I ran php artisan migrate with output: Migrated: 2016_05_20_192337_create_sub_table.
• Then I tried php artisan migrate:rollback and got output: [Symfony\Component\Debug\Exception\FatalThrowableError] Fatal error: Class 'CreateSubTable' not found.
• Then I ran composer dump-autoload and tried the rollback again, with success: Rolled back: 2016_05_20_192337_create_sub_table.

Did you try this?

[minhchu]

@mrk-j it looks like your Laravel isnt working properly. Because after creating migration, Laravel always runs composer dump-autoload in this file

[mrk-j]

@minhchu I just copied another migration to try this, so composer dump-autoload didn't run. I just assumed this was the case. Can you confirm this issue doesn't exist?

[minhchu]

Ah, sorry for the misunderstanding. If you just copied you have to dump autoload so that Laravel can know your migration files.
If you use php artisan make:migration, Laravel dump autoload for you automatically. And I think this is not an issue.
As @leesleefeng explained, that is the default behaviour, we can close this issue.

[billmn]

@warrickhill This issue can be closed?

[anderly]

See my PR above. This is still an issue.

For example, I have a multi-tenant app with one main application/security database and separate tenant databases. I keep tenant migrations stored in a tenant subfolder of the migrations folder. I have a custom Artisan command (php artisan migrate:tenant) which, in turn, calls php artisan migrate for each tenant and passes the --database=tenant option to specify the tenant database connection and the --path option to specify the path to the tenant migrations (i.e. database/migrations/tenant. This works fine and executes the migrations against the tenant database(s), but if I try to run php artisan migrate:rollback --database=tenant, it tries to rollback the migrations in the main migrations folder. So, the --path option was needed on the rollback, refresh and reset commands in order to support this.