- How do I install axn/laravel-pk-int-to-bigint?
- Install it as a development dependency with composer require --dev axn/laravel-pk-int-to-bigint. Because it is schema tooling and not a runtime dependency, there is no reason to ship it to production. The package exposes Artisan commands that discover integer primary keys and generate the migrations needed to widen them to bigint.
- Which Laravel and PHP versions does this package support?
- The package targets modern Laravel projects, typically Laravel 8 through 12, on PHP 8.1 or newer. You should confirm the exact constraints in the package's composer.json before adopting it, since the version matrix is narrow on a package this small. Note that Laravel 11 changed the default schema-alteration path away from Doctrine DBAL, so check which code path your Laravel version uses.
- Which database drivers are supported?
- The package is aimed primarily at MySQL and MariaDB, which is where the legacy increments() INT primary key pattern is most common. Behavior differs materially on PostgreSQL, and SQLite requires full table rebuilds for column type changes, so verify driver support in the README before relying on it. Test on the exact driver and version you run in production rather than assuming parity.
- Does it update foreign keys that reference the primary keys?
- Yes, the package updates related foreign key columns along with the primary keys, which is essential because InnoDB requires FK columns to be type-identical to the columns they reference. It works by dropping and recreating constraints in the correct order across tables. Review the generated migrations by hand, particularly for polymorphic *_id columns, pivot tables, and composite keys, since those are the cases most likely to be handled by inference rather than certainty.
- Is it safe to run on a production database?
- Widening INT to BIGINT is lossless for the data itself, but DDL is non-transactional on MySQL, so a partial failure can leave you with dropped foreign keys and a half-migrated schema. On large tables, changing a primary key column type forces a full table rebuild, which is the dominant risk rather than the package's logic. Clone production structure and row counts to staging, measure lock duration and replica lag, and run it in a maintenance window with a snapshot in hand.
- Can I roll back the conversion if something goes wrong?
- Narrowing BIGINT back to INT is only lossless if no value exceeds the 32-bit signed maximum, so a naive rollback can truncate or fail. Because the underlying ALTER TABLE statements are not transactional on MySQL, there is no automatic rollback mid-run. The reliable recovery path is restoring from the pre-migration snapshot you took before executing.
- Is the migration idempotent, and does it skip columns that are already bigint?
- Idempotency matters here because a partially applied run leaves foreign keys in an inconsistent state and you will want to re-run safely. Check whether the discovery step detects existing BIGINT columns and already-correct constraints before generating or executing changes, and confirm that behavior on a scratch database. If it is not idempotent, treat each generated migration as a one-shot artifact and gate it behind a schema check.
- How do I test the migrations before merging them?
- Install the package on a feature branch and run its scan command against a staging schema cloned from production, including realistic row counts rather than an empty copy. Review every generated migration manually, as you would a draft pull request, instead of trusting the output as a runnable artifact. Then dry-run on a production-sized copy, verify foreign key integrity and row counts afterward, and run application smoke tests before merging to main.
- What are the alternatives to this package?
- You can write the migrations yourself with Laravel's Schema builder using bigIncrements and explicit foreign key drops and re-adds, which is more work but fully under your control. For MySQL, online DDL tooling such as gh-ost or pt-online-schema-change handles the locking problem that plain ALTER TABLE does not. Given the low adoption of this package, many teams review it as a reference implementation and vendor the parts they need.
- Is this package actively maintained and production-ready?
- It has a small adoption footprint with very few stars and dependents, which means effectively no public production evidence base. Treat it as a development-time remediation tool to audit, test, and possibly vendor rather than a trusted black box in your deployment pipeline. Check the repository's recent commits and issue activity before committing to it, and be prepared to maintain your own fork.