- Can I use kibatic/datagrid-bundle in a Laravel application?
- No. This is a Symfony bundle that depends on the Symfony kernel, bundle registration in bundles.php, the Symfony DI container, and typically Twig and Doctrine. It ships no Laravel service provider, Eloquent integration, or Blade views. Bridging a Symfony bundle into Laravel's container costs far more than the grid is worth, so treat this as a no for Laravel projects.
- How do I install kibatic/datagrid-bundle?
- Install it with Composer using composer require kibatic/datagrid-bundle. In a Symfony app, register the bundle in config/bundles.php or let Symfony Flex handle auto-registration. Then add a small YAML configuration tree and create per-resource grid classes that define columns, filters, sorting, and pagination. Before installing, confirm the version constraints resolve against your pinned PHP, Symfony, Doctrine, and Twig versions.
- What are the requirements for using this package?
- It requires a Symfony application; the bundle is built around Symfony's kernel, DI container, and bundle system. In practice you will also need Twig for rendering and Doctrine ORM or DBAL as the data source, though the exact hard requirements should be verified in composer.json. It will not run standalone outside a Symfony application.
- Which Symfony and PHP versions does DatagridBundle support?
- The exact supported versions are declared in the package's composer.json, so check that file rather than assuming. Because the package has almost no adoption, there is no community evidence of which Symfony or PHP combinations are actually tested in practice. Run composer resolution against your pinned versions and confirm nothing core gets downgraded.
- What should Laravel developers use instead of this bundle for data grids?
- For Laravel, use Eloquent-based tooling such as Livewire table components, a DataTables integration like yajra/laravel-datatables, or query builder pagination rendered through Blade. Alternatively, read this bundle's grid, column, and filter abstractions and reimplement the roughly 200 lines you actually need against Eloquent. That is a design-input decision, not an adoption decision.
- Is kibatic/datagrid-bundle actively maintained?
- The available signals are weak: roughly 14 GitHub stars, zero dependents, and stewardship by a single small consultancy, which means bus factor is one. The recorded last release date is future-dated, which is anomalous and should be verified as a real tag rather than a mistagged dev branch or metadata error. There are no example repos or downstream codebases to learn from, so you would be the most significant adopter.
- Is it safe to use in production?
- Adoption risk is high because of near-zero community gravity, a single maintainer, and unknown or likely thin test coverage. MIT licensing limits legal exposure, but it does not reduce operational risk. Vet transitive dependencies for open CVEs and confirm your dependency policy accepts single-maintainer, low-adoption packages before committing.
- What license is DatagridBundle released under, and can I fork it?
- It is MIT licensed, so legal risk is effectively zero and forking is explicitly permitted. If you adopt it, consider pinning to a specific commit or tag you have verified and keeping a fork you control. That mitigates the bus-factor risk of relying on a single small consultancy for upstream fixes.
- How does the bundle handle sorting, filtering, and pagination?
- You define columns, filters, sorting, and pagination per grid class with minimal code, then render the result as a table for admin, reporting, or data-heavy screens. The grid is built from Doctrine queries or plain arrays, which makes it reusable across resources. What is less clear from the available material is the underlying query strategy, so verify that before relying on it at scale.
- Does it scale to large datasets and complex queries?
- That depends on how the bundle builds queries: whether it uses the Doctrine Paginator, custom DQL, or raw SQL determines your scaling ceiling. This is not documented in the material available, so inspect the query-building code and benchmark against a realistic dataset size. If you have complex joins or heavy filters, test the generated SQL and execution plans before committing to adoption.