- How do I install josezenem/laravel-make-migration-pivot?
- Install it as a dev dependency with composer require --dev josezenem/laravel-make-migration-pivot. Laravel's package auto-discovery registers the Artisan command, so no service provider registration or config publishing is required. Because it only scaffolds files, it should stay in require-dev and never ship to production.
- Which Laravel versions does this package support?
- The package targets Laravel 9 and above, since it emits migrations in the closure-based Schema::create format introduced in Laravel 9. Whether it explicitly tracks Blueprint changes in Laravel 10, 11 and 12 is not documented in the package metadata. Pin the version and add a CI smoke test that runs the command and migrates a scratch database on your Laravel minor version.
- How do I generate a pivot migration between two models?
- Run the package's Artisan command and pass the two model classes as arguments (check the README for the exact signature). It writes a new migration file into database/migrations containing a Schema::create call with the derived pivot table name, foreign key columns and timestamps. Review and edit the file like any hand-written migration before committing it.
- How does the package name the pivot table?
- It follows Laravel's convention: the two model names in alphabetical order, singular and snake_cased, joined by an underscore, for example post_user for a Post and User relationship. That matches what belongsToMany expects by default, so no extra configuration is needed on the relationship. If your models deviate from the convention, verify the generated table name before running the migration.
- Does it respect custom $table names, $primaryKey or $keyType overrides on my models?
- The package works by convention inference from the model class names, so models with a custom protected $table, a non-incrementing or UUID/ULID $keyType, or a custom $primaryKey may produce an incorrect schema silently. Treat the generated file as a starting point and check the column types and constrained() targets. This behaviour is not confirmed in the package metadata, so test it against your own models.
- Does the generated migration include timestamps and cascade deletes?
- Timestamps are part of the package's stated purpose, so the generated pivot table normally includes a timestamps() call. Whether foreign keys are emitted as the modern foreignId()->constrained()->cascadeOnDelete() idiom or the older unsignedBigInteger form depends on the package version. Open the generated file and confirm it matches the conventions your team standardises on.
- Can it handle self-referencing pivots like followers/following or polymorphic pivots like taggables?
- Self-referencing and polymorphic many-to-many relationships are exactly where a two-models-in, one-migration-out tool tends to diverge from what you would hand-write. The package does not document special handling for these cases. Generate the file, then rename the duplicate foreign key columns or swap in morphs() manually before migrating.
- Can I specify a custom pivot table name or custom pivot model?
- The package is built around convention inference from the two model arguments, and a custom pivot table or pivot model argument is not documented. The practical workaround is to generate the migration and then edit the table name and column definitions directly, since the output is a plain migration file. There is no lock-in or custom migration format to escape.
- Does the package affect my application in production?
- No. It ships a single Artisan command with no service provider boot logic, no request-path code and no configuration to publish, so it is purely local and CI tooling. The only artifact that reaches production is the migration file you review, edit and commit. That makes the blast radius essentially zero beyond the correctness of that file.
- Is the package safe to depend on, and what if it gets abandoned?
- It is MIT-licensed, small and has a single maintainer, so the bus factor is one even though a 2025 release is a positive recency signal. The risk is cheap to mitigate: fork it, vendor it into a tools directory, or replace the command with your own stub if maintenance stops. Alternatively, stick with make:migration plus manual editing, or an internal scaffolding command if your team already has one.