- What does exolnet/laravel-sqlite-fluent-drop-foreign do?
- It restores Laravel's fluent dropForeign() operation on SQLite by working around SQLite's lack of ALTER TABLE ... DROP CONSTRAINT, rebuilding the table as needed. It is a migration-layer compatibility shim, not a runtime feature. Use it when your migrations call dropForeign() and your test or local environment runs SQLite.
- How do I install this package for Laravel?
- Require it with Composer, typically as a dev dependency since SQLite is often used for tests and local development. No credentials or configuration are required. Then run your migrations that use dropForeign() against SQLite.
- Which Laravel and PHP versions does this package support?
- Version 1.12.0 requires PHP 8.3+ and Laravel 12+. Earlier 1.11.x releases support PHP 8.2 and Laravel 11, so pin 1.11.* if you have not upgraded your platform yet. The v1.12.0 release was published as a minor version but is a breaking platform change.
- Is this package safe to use in production?
- It only affects schema building during migrations, so it has no runtime request path. That keeps its blast radius small, but it is mainly intended for SQLite test and local environments. Production use is reasonable only if you actually run SQLite migrations there.
- Why do I get an error dropping a foreign key on SQLite in Laravel?
- SQLite has limited ALTER TABLE support and cannot natively drop a foreign key constraint. Laravel's fluent dropForeign() therefore needs a table rebuild workaround. This package provides that workaround so the migration can complete cleanly.
- Does exolnet/laravel-sqlite-fluent-drop-foreign support Laravel 11?
- Laravel 11 is supported only in the 1.11.x line, not in 1.12.0. If you are on Laravel 11 or PHP 8.2, constrain the package to 1.11.* to prevent Composer from pulling the breaking release. Upgrade to 1.12.0 only after moving to PHP 8.3+ and Laravel 12+.
- Is v1.12.0 a breaking change despite being a minor version?
- Yes. The v1.12.0 release drops PHP 8.2 and Laravel 11 support under a minor version number, which violates semantic versioning expectations. Projects using ^1.11 can receive it on a routine composer update and then fail dependency resolution on older runtimes. Composer fails loudly, but CI pipelines can go red without code changes.
- What are alternatives to this package for SQLite foreign key drops?
- You can inline the SQLite table-rebuild logic yourself or move those migration tests to a database that supports dropping foreign keys natively, such as MySQL or PostgreSQL. If your test suite does not use SQLite, removing the dependency is the cheapest option. The package is a narrow shim, so inlining is feasible but adds maintenance.
- Does this package conflict with doctrine/dbal or Laravel schema builder internals?
- The package has historically been sensitive to Laravel's schema-builder internals. Before adopting v1.12.0, confirm the constraint set resolves cleanly alongside laravel/framework and doctrine/dbal if present. The real acceptance gate is running a migration test that exercises dropForeign() against SQLite.
- Is this package actively maintained, and what if it is abandoned?
- It is a single-maintainer, low-velocity utility package, so bus factor and long-term support are the dominant risks. Recent dependency housekeeping is a positive maintenance signal, but it does not guarantee ongoing support. If abandoned, you can inline the table-rebuild workaround or migrate SQLite foreign-key-drop tests to a database with native support.