お疲れ様です。

Groです。

Laravelの管理画面パッケージを利用しようと考えた時、
色々な選択肢があると思いますが、BREADという仕組みが小規模開発にマッチしていたのでVoyagerを採用してみました。

良い点

爆速で管理画面構築

フロントとの共存が可能

useModelをすることでVoyager側の使用するモデルを変更できるので、UserモデルをAdminUserモデルとしました。

// AppServiceProvider.php
    public function boot(): void
    {
        // ...中略...
        $voyager->useModel('User', AdminUser::class);
    }

GuardはVoyagerGuardをadminに設定しました。

// AppServiceProvider.php
    public function register(): void
    {
        Sanctum::ignoreMigrations();
        $this->app->singleton('VoyagerGuard', function () {
            return 'admin';
        });
    }

アクションの追加が簡単

BREAD用のViewの個別カスタマイズが可能

resources/views/vendor/voyager/[slug-name]/browse.blade.php
などを作成することでそちらを参照してくれます。

課題

日本語の翻訳がちょいちょい抜けてる

改善せねば、なんですが、
取り急ぎ以下を切り出して解決しました。
resources/lang/vendor/voyager/ja/generic.php

Githubがあまり活発ではない？

最終コミットが6ヶ月前とか

検索クエリに複合条件が使えない

仕方なくscopeを定義し、massActionでscopeを切り替えて回避しました。
※複数人で操作をすると検索条件が共有されてしまいますが、運用上複数人で操作することは無いため許容しました。

バグ？でリレーションの検索が行なえない

修正プルリクエストはあるようですが、まだマージされていません。

DBのVIEWに対応していない

リレーションの検索が行なえないならばとVIEWが使えないか見てみましたが、対応していませんでした。
追加や削除が行なえないのでしょうがないかとは思います。

仕方がないのでデータを一つのテーブルに集約させることにしました。
冗長的になってしまいましたが許容しました。

massAction()でフロントの検索条件が引き継げない

massAction()の第二引数で$comingFromが取れるので、URLパースして検索条件を構築しました。
しかし、基本的には第一引数の$idsをとって操作するという使い方が正しいかと思います。

まとめ

色々と課題点もありますが、爆速で管理画面が作成できるのは非常に便利だったので今後も他の案件（大規模案件でカスタマイズ必須であれば向かないと思いますが）で使っていきたいと思います。
コミュニティが活性化してくれればとても良いのですが…。
他のパッケージの方が良かったりするのであれば試してみるので教えてください。