Laravelでマイグレーションファイルを初期化しようとしたらハマってしまったことについて

どうも、プログラミング初学者のものです。

laravel/vue.jsを使用してアプリを作成しています。
現在は作成の最終段階に入りコードの整理しているのですが、アプリの設計段階でデータベースのテーブル構成をしっかり構築できなかった為、変更箇所が多数出てしまい追加のmigrationファイルの量も膨大になってしまいました。

この状況がダメなのかどうか初学者の私には判断できないのですが、コードレビューする際にかなり見づらい状況なのでmigrationファイルを初期化できないか調べました。
その結果をここにまとめさせていただきます。

※migrationファイルは全てmigratされrun状態にあるていです。

現在の状況

このように悲惨な状況となっております。

root@6f166bf3b0fd:/work/backend# php artisan migrate:status

+------+-----------------------------------------------------------------+-------+
| Ran? | Migration                                                       | Batch |
+------+-----------------------------------------------------------------+-------+
| Yes  | 2014_10_12_000000_create_users_table                            | 1     |
| Yes  | 2014_10_12_100000_create_password_resets_table                  | 1     |
| Yes  | 2019_08_19_000000_create_failed_jobs_table                      | 1     |
| Yes  | 2021_02_12_064721_create_logs_table                             | 1     |
| Yes  | 2021_02_12_064843_create_comments_table                         | 1     |
| Yes  | 2021_02_12_064912_create_favorites_table                        | 1     |
| Yes  | 2021_02_12_064942_create_followers_table                        | 1     |
| Yes  | 2021_02_12_065012_create_events_table                           | 1     |
| Yes  | 2021_02_23_101650_add_event_explanation_to_events_table         | 1     |
| Yes  | 2021_02_25_104334_create_event_logs_table                       | 1     |
| Yes  | 2021_02_28_062711_modify_logs_table                             | 1     |
| Yes  | 2021_03_02_064731_create_event_logs_events_table                | 1     |
| Yes  | 2021_03_22_231707_add_user_text_to_users_tables                 | 1     |
| Yes  | 2021_03_22_233530_rename_uiser_text_to_user_text_on_users_table | 1     |
| Yes  | 2021_03_22_234218_modify_users_table                            | 1     |
+------+-----------------------------------------------------------------+-------+

php artisan migrate:rollback

この方法は初学者の私でも調べる前から知っていましたので最初に行いました。（実際に使ったことはなかった）

php artisan migrate:rollback --step=5

結果は

root@6f166bf3b0fd:/work/backend# php artisan migrate:rollback --step=5
Rolling back: 2021_03_22_234218_modify_users_table
Rolled back:  2021_03_22_234218_modify_users_table (0.16 seconds)
Rolling back: 2021_03_22_233530_rename_uiser_text_to_user_text_on_users_table

   Doctrine\DBAL\Schema\SchemaException  : There is no column with name 'uiser_text' on table 'users'.

  at /work/backend/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/SchemaException.php:86
    82|      * @return SchemaException
    83|      */
    84|     public static function columnDoesNotExist($columnName, $table)
    85|     {
  > 86|         return new self(
    87|             sprintf("There is no column with name '%s' on table '%s'.", $columnName, $table),
    88|             self::COLUMN_DOESNT_EXIST
    89|         );
    90|     }

  Exception trace:

  1   Doctrine\DBAL\Schema\SchemaException::columnDoesNotExist("uiser_text", "users")
      /work/backend/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/Table.php:711

  2   Doctrine\DBAL\Schema\Table::getColumn("uiser_text")
      /work/backend/vendor/laravel/framework/src/Illuminate/Database/Connection.php:882

  Please use the argument -v to see more details.

エラーが出てしまいました、、、

調べた結果、エラーの出ているファイルではカラムのリネーム処理の書き方が間違っており、テーブル定義変更処理を一緒に行っている状態になっていました、、、（こんなミスをするのは自分だけなのでは）
その為テーブル定義のrollback処理を行う際にリネームする前のカラム名が参照され「そんなカラム名は存在しないよ」というエラーが出てしまったのかと思われます。

ちなみにその時エラーが出てしまったコードがこちらです

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class RenameUiserTextToUserTextOnUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('users', function (Blueprint $table) {
            //
            $table->renameColumn('uiser_text', 'user_text');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('users', function (Blueprint $table) {
            //
            $table->renameColumn('uiser_text', 'user_text');
        });
    }
}

Schema::renameとするとこがSchema::tableになってしまっています、、、

migrateするときは何もエラーが出なかったため気づかずに進めていました、、、

php artisan migrate:reset

これは全てのmigrationファイルにrollback処理をおこいなってくれるそうです

ただ、私の作ったmigrationファイルは先ほどと同じようにエラーが出てしまいました、、、

問題のファイルを削除してもエラーは直らないまま、
これはもうmigrationsテーブルの履歴を削除したりして補正するしかないか半分諦めていたところ、何やらうまくいきそうな方法を見つけたので書かせていただきます。

手動で削除後　composer dump-autoload

migrationファイルを手動で全て削除した後

root@6f166bf3b0fd:/work/backend# composer dump-autoload

すると

Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: laravel/tinker
Discovered Package: laravel/ui
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
Generated optimized autoload files containing 5561 classes

上手く行ったような

あらためて

root@6f166bf3b0fd:/work/backend# php artisan migrate

実行すると

Nothing to migrate.

と、綺麗さっぱりな状態になりました！！

vendor/composer/autoload_classmap.php というファイルにクラス名とファイルのマッピングが記録されていて、artisan make:migration が実行時これを元にインスタンスの生成をしているそうです。(知りませんでした)

なのでcomposer dump-autoloadを実行しclassmapを最適化することでエラーが出なくなるそうです。

結局、最初からデータベースの構築をちゃんと行い、丁寧にコードを書いてればこんなところでハマることもなかったのでしょう、、、
以後気をつけます、、、