- Is makoso/data-grid-bundle a Laravel package?
- No. makoso/data-grid-bundle is a Symfony bundle, not a Laravel package. It registers through Kernel::bundles(), configures via Symfony Extension and Configuration classes, and renders tables with Twig. Laravel has no bundle registration mechanism, so it cannot be adopted as a normal Composer dependency in a Laravel application.
- What does makoso/data-grid-bundle actually do?
- It builds reusable, configurable data grids from PHP arrays or Doctrine queries. You declare columns with custom rendering, and it provides sorting, filtering, pagination, and Twig-rendered tables. The goal is consistent, maintainable admin listing screens without hand-written table code.
- Can I install makoso/data-grid-bundle in a Laravel 10 or 11 app?
- Composer may resolve the package, but there is no ServiceProvider, no publishable config, and no Blade views. Using it means booting a Symfony dependency injection container inside Laravel or extracting the grid domain logic and rebuilding the framework-facing layer. That is architecture work, not a dependency addition, and v0.2.7 does not raise the PHP or Symfony floor in any documented way.
- Does makoso/data-grid-bundle support Eloquent or Laravel's query builder?
- No. Its data layer is Doctrine ORM plus plain array sources, while Laravel persistence is Eloquent and the query builder. The column definitions, filter types, sorting contracts, and pagination logic are transferable abstractions, but the source adapters are not. Realistically you would write an Eloquent adapter from scratch, which is most of the work the package was meant to save.
- How do you install and configure makoso/data-grid-bundle in Symfony?
- Install it with Composer, register the bundle in your Kernel::bundles() array, and configure it under config/packages using the bundle's Extension and Configuration classes. Grid types and column definitions are then declared in PHP and rendered through Twig templates. None of these steps map onto Laravel's provider, config publishing, or view conventions.
- Is makoso/data-grid-bundle actively maintained?
- It is minimally maintained rather than abandoned. Version 0.2.7 was published recently, but it is a single additive feature, session-backed filter persistence, after years of silence. There is no evidence of PHP 8.x support, Symfony 5 or 6 compatibility, Doctrine upgrades, security triage, or dependency refreshes, and 0.2.7 is a pre-1.0 release train with no semver stability contract.
- Does the v0.2.7 session filter persistence work with Laravel sessions?
- No. The feature almost certainly reads and writes filter state through Symfony's session service, which does not exist as such in Laravel. Porting it means re-implementing filter-state serialization against Illuminate\Session. That is small in isolation, but it is another Symfony coupling point that cannot be adopted as-is.
- What are the Laravel alternatives to makoso/data-grid-bundle?
- For Laravel admin listings, consider Filament Tables, Orchid Platform, Livewire tables, or spatie/laravel-query-builder combined with Blade views. These give you native Eloquent integration, Blade rendering, and filter persistence without a Symfony container. Filter persistence in particular is commodity behavior with several native Laravel options.
- How would I test or integrate makoso/data-grid-bundle in a Laravel codebase?
- The defensible path is selective extraction, treating the repository as a reference implementation for grid configuration semantics such as column metadata, filter types, and sorting contracts. You then rebuild the surface natively in Laravel with an Eloquent adapter, Blade views, and Illuminate session-backed state. Budget roughly two to four weeks for a small team, versus open-ended integration of a minimally maintained 0.x dependency.
- Is makoso/data-grid-bundle safe for production in a Laravel app?
- Technical risk is high. The package is pre-1.0 with no semver guarantees, minor bumps may carry breaking changes, and the Composer constraint, deprecation, and SCA exposure should be assumed present until verified against the actual composer.json in 0.2.7. Adopting it also means owning a fork indefinitely, including security response. For a Laravel application, native alternatives are the lower-risk choice.