Dibi Laravel Package

Product Decisions This Supports

• Build vs. buy: Avoid building and maintaining a custom bridge between Laravel and Dibi. This package provides the integration layer, letting the team focus on product work rather than database plumbing. With v1.0.4 it also supplies a ready-made database dashboard, which is a second build-vs-buy decision the team no longer has to make.
• Roadmap compatibility: The package is now post-1.0 and tracks current Laravel (11–13) — the earlier "pre-1.0" adoption risk is retired. v1.0.4 is a patch on top of that line: no breaking changes and no republish step, so it can ride along in a normal maintenance window.
• Legacy modernization: If existing applications, modules, or team expertise are invested in Dibi, this package supports an incremental migration to Laravel instead of a risky full rewrite.
• Coexistence strategy: Teams can use Dibi's database layer alongside Eloquent/Query Builder, allowing legacy data access patterns to remain while new features follow standard Laravel conventions.
• Operational reliability: v1.0.4 fixes a failure mode where a remembered but unconfigured connection produced a 500 on every dashboard request with no UI path to recovery (the connection selector lives on the broken page). The package now discards an unusable remembered selection, falls back to the first configured connection, and rejects selections not present under database.connections. This is a support-load and on-call quality-of-life fix, not a feature.
• Performance / cost: The index metadata payload sent to the browser was duplicated (mapped + raw); v1.0.4 removes roughly 40% of that payload on every dashboard load. Relevant if the dashboard is used as a day-to-day internal tool over large schemas.
• Quality signal for adoption: Test coverage was extended to the connection-selection endpoint, the dashboard controller (including the JSON contract the frontend consumes), the published-asset check, the repository factory's unsupported-driver error, and the SQLite repository — completing coverage of all three supported drivers. This materially lowers the "will it break silently on our stack?" risk that gates adoption.
• Feature/use-case fit: Relevant for Dibi-based reporting, multi-database access, lightweight query building, internal DB browsing/admin tooling, or gradual adoption of Laravel in PHP estates.

When to Consider This Package

• Strong fit: You have an existing Dibi codebase, team familiarity with Dibi, or a roadmap to migrate legacy PHP applications into Laravel incrementally.
• Strong fit: You need Dibi-specific query/database capabilities while still using Laravel's service container, configuration, and deployment model.
• Strong fit: You want a lightweight in-app database dashboard (table/index metadata, connection switching) without standing up a separate admin tool — and you want connection selection constrained to database.connections rather than free-form.
• Compatibility check: The 1.x line targets current Laravel (11–13). Confirm the installed package version matches your target Laravel release, and confirm your driver is one of the three with completed test coverage (MySQL, PostgreSQL, SQLite) — anything else is untested territory.
• Operational check: Upgrading to v1.0.4 is a plain patch: no breaking changes, no asset changes since v1.0.3, so no php artisan dibi:publish required. If you are on an older 1.x with asset changes pending, plan the publish step separately.
• Migration note: If any environment currently has a stale/unconfigured connection remembered, expect behaviour to change from "500 forever" to "fall back to first available connection." That is the fix, but verify the fallback lands on the connection you'd want in each environment.
• Look elsewhere: For greenfield Laravel applications with no Dibi investment, standard Eloquent/Query Builder is the lower-risk default.
• Look elsewhere: If you require commercial support/SLA or broad community maintenance guarantees. The 1.0 milestone resolves the API-stability objection, but the package remains niche with a small maintainer base — treat bus-factor and long-term maintenance as the residual adoption risk.
• Upgrade caution: v1.0.4 is a reliability and test-coverage release, not a feature expansion. Smoke-test the dashboard after upgrade, particularly connection switching and index rendering, since both changed.

How to Pitch It (Stakeholders)

• Executives: "This is a low-cost compatibility layer that reduces the cost and risk of modernizing Dibi-based PHP systems onto current Laravel. It has reached a stable 1.0 API, and v1.0.4 is a patch that fixes a dashboard outage mode and cuts a chunk of dashboard payload — no migration work, no republish, no breaking changes."
• Engineering: "v1.0.4 is a patch on the 1.x line. Two fixes: connection selection is now validated against database.connections so a stale remembered connection can't permanently 500 the dashboard; and TableIndex no longer ships raw plus mapped fields, cutting ~40% of index payload. Test coverage now spans the dashboard controller and JSON contract, connection endpoint, asset check, repository factory, and all three drivers. It is a tactical integration package for Dibi-heavy work, not a replacement for Eloquent or a reason to deviate from standard Laravel patterns elsewhere."
• Product/roadmap: "Use this package when it de-risks an existing Dibi migration or unlocks legacy data access inside Laravel — and now also when you'd otherwise build an internal DB dashboard. Keep it scoped to those use cases; avoid adopting it as a default database layer for greenfield product work."