- What is cuonggt/laravel-dibi and when should I use it instead of Eloquent?
- It is an adapter package that binds the Dibi database abstraction layer into Laravel's service container and publish pipeline, giving you Dibi's connections, query builder, transactions, and logging inside a Laravel app. It is not a replacement for Eloquent, so the fit is narrow: it makes sense where Dibi is already a house standard or where you are porting a Nette/Dibi application into Laravel and want to avoid rewriting the data layer. For greenfield Laravel work, Eloquent plus the query builder covers the same ground with far larger community support.
- How do I install cuonggt/laravel-dibi and which Laravel versions does it support?
- Install with composer require cuonggt/laravel-dibi, then run php artisan dibi:publish to publish the configuration and assets. As of v0.7.0 the service provider auto-registers through bootstrap/providers.php, so a clean install on Laravel 11 or 12 is genuinely zero-config for the first time. Laravel 13 support was added in the same release; teams on Laravel 10 or below gain nothing from it and are on an unsupported path. Confirm the PHP version floor in the package's composer.json before planning, since the changelog does not state it.
- How do I configure Dibi database connections in a Laravel application?
- Run php artisan dibi:publish and define your connections in the package's published config file, keeping credentials in your .env as you would for any Laravel database setup. Once configured, you can resolve Dibi through the container and use its familiar API for queries, transactions, and logging. Keep the configuration under version control and avoid hand-editing published files, since re-publishing will overwrite them.
- Why doesn't laravel-dibi work out of the box on Laravel 11 or 12?
- Before v0.7.0 the service provider was not registered in bootstrap/providers.php on the modern Laravel skeleton, so the package did not function on a clean Laravel 11 or 12 install without manual provider wiring. Upgrading to v0.7.0 or later resolves this, and after installing you should verify the provider actually appears in bootstrap/providers.php. That a fix this basic persisted across the Laravel 11 and 12 lifecycle is a maturity signal worth weighing.
- Is cuonggt/laravel-dibi stable enough to use in production?
- The package is pre-1.0, which means there is no API stability guarantee and minor version bumps may break call sites. If you adopt it, pin exact versions in composer.json and build a regression suite around your Dibi queries and transactions so an upgrade failure is caught immediately. Also keep a fork or vendoring contingency in mind, since the upstream maintainer base for both the package and Dibi itself is small.
- Can I use laravel-dibi alongside Eloquent and Laravel's DB facade?
- Yes. The package is an adapter, not a replacement: it slots in alongside Laravel's DB manager, so you can keep Eloquent models and the query builder for most of the application while using Dibi where you specifically need it. A common pattern is to wrap Dibi calls behind a thin repository layer so application code is not coupled directly to a pre-1.0 package API. That also makes it easier to swap the implementation later if needed.
- Is upgrading laravel-dibi from v0.6.x to v0.7.0 a drop-in change?
- No. The Vite dependency bump requires re-running php artisan dibi:publish, which will overwrite previously published assets, so any local edits to those files must be diffed and re-applied first. Treat the upgrade as a controlled change: take a backup, review what the publish command writes into your tree, and have a rollback plan. Run your Dibi query regression tests before deploying.
- Why does a PHP database package ship Vite assets, and what does dibi:publish write into my app?
- The package includes publishable frontend assets built with Vite, which means it carries a JavaScript dependency tree that your dependency scanners will track and flag. The dibi:publish command writes the package configuration and those assets into your application tree. Review the published output and diff it on every upgrade so you know exactly what is being added to your codebase.
- How should I test an application that uses laravel-dibi for queries and transactions?
- Wrap Dibi usage behind a repository or service layer and test that layer against a real test database rather than mocking the Dibi API, since the query construction is the part most likely to break on a minor version bump. Cover transactions, rollbacks, and connection configuration explicitly. Add an upgrade smoke test in CI so that bumping the package fails fast if call sites change.
- What are the alternatives to laravel-dibi, and what is the upstream maintenance risk?
- For most Laravel projects the natural alternatives are Eloquent and the query builder, or Doctrine DBAL if you want a mature, widely used abstraction layer. Dibi is the right choice mainly when you already have a Dibi or Nette footprint, and its maintainer base and release cadence are small and geographically concentrated. That bus factor applies to both the Laravel adapter and the underlying Dibi library, so plan for pinned versions and a fork or vendoring contingency.