Laravel Sqlite Fluent Drop Foreign Laravel Package

Technical Evaluation

Architecture fit. eXolnet/laravel-sqlite-fluent-drop-foreign is a narrow compatibility shim: it restores Laravel's fluent dropForeign() schema operation on SQLite, where the platform lacks native ALTER TABLE ... DROP CONSTRAINT and therefore requires a table rebuild. Architecturally it sits in the migration layer only — no runtime request path, no service provider surface we depend on beyond schema building. That keeps blast radius small, but it also means the package's value is entirely contingent on our SQLite usage in test and local environments.

Integration feasibility. Trivial to adopt: it is a dev/test-oriented dependency with no infrastructure, credentials, or configuration. The only real work is version alignment across our application matrices.

Technical risk. The v1.12.0 release is a breaking change published under a minor version number — it drops PHP 8.2 and Laravel 11 support. Two consequences:

1. Semver violation. Consumers using ^1.11 will receive this release on a routine composer update and will get an unresolvable dependency set if they are still on PHP 8.2 or Laravel 11. Composer will fail loudly rather than silently break, but CI pipelines pinned to ^1.0 with older runtimes will go red without any code change on our side.
2. Forced platform floor. Adopting v1.12.0 implicitly commits us to PHP 8.3+ and Laravel 12+. That is a platform decision, not a package decision, and must be sequenced against the application upgrade roadmap rather than driven by a transitive dev dependency.

Secondary risk: this is a single-maintainer, low-velocity utility package. The PR is dependency housekeeping rather than feature work, which is a positive maintenance signal, but bus factor and long-term support remain the dominant risk.

Key questions.

• Are we on PHP 8.2 or Laravel 11 in any application or CI image that pulls this package?
• Do we pin exact versions (1.11.x) or ranges (^1.11)? If ranges, the breaking change is already in our dependency graph.
• Is this package a direct dependency or transitive via a starter kit / internal scaffold?
• What is our fallback if the package is abandoned — can we inline the table-rebuild logic, or migrate SQLite FK-drop tests to a database that supports it natively?
• Does Laravel 12 remove or change the underlying gap this package patches, making it redundant?
• Is there a composer.lock policy that would have caught this before it reached a shared branch?

Integration Approach

Stack fit. Only relevant if we run SQLite for tests or local development. If our test suite uses MySQL/Postgres, this package is dead weight and should be removed rather than upgraded — the cheapest resolution to a breaking change is eliminating the dependency.

Migration path. Two discrete paths, decided per repository:

• Already on PHP 8.3+ / Laravel 12+: accept v1.12.0, run composer update eXolnet/laravel-sqlite-fluent-drop-foreign, and verify the migration test suite exercises at least one dropForeign operation against SQLite.
• Still on PHP 8.2 / Laravel 11: constrain to 1.11.* immediately to stop the breaking change entering the lock file, then schedule the platform upgrade. Do not attempt to upgrade the package ahead of the runtime.

Compatibility. Confirm the constraint set resolves cleanly alongside laravel/framework and doctrine/dbal if present. The package has historically been sensitive to Laravel's schema-builder internals; a Laravel 12 jump is exactly the scenario where that sensitivity surfaces, so the migration test suite is the acceptance gate, not the composer resolve.

Sequencing.

1. Inventory: composer why eXolnet/laravel-sqlite-fluent-drop-foreign across all repositories; classify direct vs. transitive and SQLite vs. non-SQLite.
2. Remove where SQLite is not in use.
3. Pin 1.11.* where the PHP/Laravel floor is not yet met.
4. Upgrade the runtime floor on the remaining repositories, then adopt v1.12.0.
5. Add a renovate/dependabot rule that surfaces major-version-adjacent minor bumps on 0.x/1.x utility packages for review rather than auto-merge.

Operational Impact

Maintenance. Low ongoing effort — no configuration, no migrations of its own, no runtime surface. The cost is concentrated in dependency-graph hygiene: this release demonstrates the package can force a platform upgrade, so it needs to be tracked deliberately rather than passively.

Support. Single-maintainer project with small contributor volume. Reasonable to depend on for dev/test convenience; not appropriate to depend on for anything production-critical. Treat as "replaceable in an afternoon" and confirm that assumption holds by identifying the fallback (raw Schema::table rebuild or a non-SQLite test database).

Scaling. No scaling characteristics of its own. Indirect effect: SQLite-based test suites get slower as schema rebuilds multiply; if test runtime becomes a bottleneck, moving to a native-FK-dropping database removes both the performance cost and this dependency.

Failure modes.

• Composer resolve failure on CI after an unpinned update — noisy, self-revealing, low harm.
• Lock file drift where one repository upgrades and another does not, producing inconsistent platform floors across the fleet — the realistic operational hazard here.
• Silent behavioral divergence if Laravel 12 changes schema-builder internals in a way the package does not yet cover; this would appear as failing migrations in SQLite tests rather than production incidents.
• Abandonment: no upstream fix for a future Laravel schema change, blocking the next platform upgrade. Mitigation is the inlining fallback, not vendor support.

Ramp-up. Effectively zero for engineers — it is invisible when working. The ramp-up cost belongs to platform/DevOps, who must own the PHP/Laravel floor decision and the dependency pinning policy that this release makes necessary. Recommend a short note in the internal dependency register recording the platform floor implication and the removal-candidate status for any non-SQLite repository.