Laravel Sqlite Fluent Drop Foreign Laravel Package

Product Decisions This Supports

• Dev/test parity on SQLite. This package removes a specific, recurring class of "works in CI, breaks in prod" failures: migrations that drop foreign keys run cleanly against SQLite in tests and against MySQL/Postgres in production. That directly affects how much confidence you can place in a green test suite.
• Single migration path vs. dual maintenance. It lets one set of migrations serve all environments, avoiding per-driver conditionals (if (DB::getDriverName() === 'sqlite')) or duplicated migration files — a recurring tax on every schema change.
• CI cost and speed. Supports keeping SQLite as the test database (fast, zero-infra, parallelizable) rather than standing up MySQL/Postgres services in CI purely to satisfy migration quirks.
• Rollback and migrate:fresh reliability. Enables local migrate:rollback / reset workflows that would otherwise fail on SQLite when reversing foreign keys — affects developer loop time, not just correctness.
• Build vs. buy. The underlying workaround (table rebuild to drop an FK in SQLite) is well-understood but fiddly and easy to get subtly wrong around indexes, PRAGMA foreign_keys, and data preservation. Buying a small focused package is usually cheaper than owning that logic — but see the maintenance caveat below.
• Roadmap input on SQLite as a first-class target. Whether you invest in SQLite for local/CI (and possibly edge/production) should be an explicit platform decision; this package is a dependency of that decision, not a driver of it.
• Upgrade sequencing. v1.12.0 forces a floor of PHP 8.3+ and Laravel 12+. That makes this release a scheduling input for your framework upgrade workstream, and it may block teams still on Laravel 11 / PHP 8.2.

When to Consider This Package

Adopt when:

• SQLite is your test/local database and any migration (including third-party package migrations) drops a foreign key — especially if you run rollbacks or migrate:fresh routinely.
• You have, or expect, divergent behavior between CI and production schemas and want the smallest possible fix rather than a CI database service.
• You are already on PHP 8.3+ and Laravel 12+ (required by v1.12.0) and your dependency constraints can absorb the package's updated dependency set.
• Your team accepts a narrow, single-purpose dependency with a small maintenance surface in exchange for removing a whole failure mode.

Look elsewhere or skip when:

• You are on PHP 8.2 or Laravel 11. v1.12.0 is a breaking platform bump; stay pinned to v1.11.x and plan the upgrade, or defer adoption. Do not let a transitive requirement silently force a framework upgrade.
• You don't drop foreign keys in migrations, or you control migrations well enough to normalize them (e.g., recreate tables explicitly, or avoid dropping FKs in reversible migrations). Then the package earns no keep.
• SQLite is your production database and your schema evolution is heavily FK-dependent — you likely need a broader strategy than a single grammar patch.
• You have a policy against micro-dependencies for migration internals, or your supply-chain review requires active multi-maintainer stewardship; validate release cadence and maintainer depth first.
• The bundled "update dependencies" changes in v1.12.0 conflict with your other pinned constraints — resolve before adopting, since a small package with tight transitive coupling can become an upgrade blocker.

How to Pitch It (Stakeholders)

For executives: This is a small, single-purpose dependency that eliminates a known source of test-versus-production drift. Without it, migrations that remove foreign keys silently fail or are skipped on SQLite, so CI passes while production schema changes behave differently — a correctness risk that shows up late and expensively. Cost is one low-footprint package; benefit is a test suite that actually represents production. The trade-off is upgrade coupling: v1.12.0 drops PHP 8.2 and Laravel 11, so adoption should be sequenced with our framework upgrade rather than ahead of it.

For engineering: It patches SQLite's inability to drop foreign keys through Laravel's fluent migration syntax, so dropForeign works on SQLite without hand-rolled table-rebuild logic. v1.12.0 is a breaking change in platform support only — no new features: requires PHP 8.3+ and Laravel 12+, with dependency bumps included. Actions: (1) pin ^1.11 if you're still on Laravel 11/PHP 8.2 and track the upgrade; (2) on Laravel 12, adopt and verify with a rollback test in CI, not just migrate; (3) review the dependency diff in the PR before merging, since transitive constraints are the likeliest source of friction; (4) add a migration rollback step to CI so the package's value is actually exercised rather than assumed.