makoso/data-grid-bundle
Makoso DataGridBundle provides a reusable data grid for Symfony applications, with configurable columns, sorting, filtering, pagination, and Twig-rendered tables. It helps add searchable, paginated admin lists without custom table code.
Architecture fit. Unchanged. The core finding stands: makoso/data-grid-bundle is a Symfony bundle, not a Laravel package. It registers through Kernel::bundles(), configures via Extension/Configuration classes, and renders through Twig. Laravel has no bundle registration mechanism, and its container, config publishing, and view layer are deliberately different. There is no ServiceProvider, no publishable config, and no Blade views. Adopting it in a Laravel codebase still means either booting a Symfony DI container inside Laravel or extracting the grid domain logic and rebuilding the framework-facing layer — architecture work, not a dependency addition.
Integration feasibility. Low, unchanged. The data layer remains Doctrine-based; a Laravel app's persistence is Eloquent/Query Builder. The column definitions, filtering, sorting, pagination, and source adapters are the transferable abstractions; the adapters are not. The realistic path remains a from-scratch Eloquent adapter, which is most of the work the package was meant to save. v0.2.7's session-backed filter persistence adds a second framework coupling point: the feature almost certainly reads and writes through Symfony's session service, which does not exist as such in Laravel. Porting it means re-implementing filter-state serialization against Illuminate\Session anyway — small in isolation, but it is another surface that cannot be adopted as-is.
Technical risk. High, with one correction to the prior assessment. The package is not fully dormant: v0.2.7 was published, so the "no releases since 2020-09-02" claim no longer holds and the abandonment language should be softened to "minimally maintained." Nothing else materially improves. The release is a single additive feature — a session toggle for filter state — with no evidence in the notes of PHP 8.x support, Symfony 5/6 compatibility, Doctrine upgrades, security triage, or dependency refreshes. The version number also matters: 0.2.7 is a pre-1.0 release train, so there is no semver stability contract for downstream consumers, and minor bumps may carry breaking changes. A one-feature release after years of silence is a weak liveness signal — it indicates a single occasional contributor, not a maintained dependency with a support posture. The Composer constraint, deprecation, and SCA exposure described previously is unchanged and should be assumed still present until verified against the actual composer.json in 0.2.7.
Key questions for the requestor.
spatie/laravel-query-builder + Blade do not?composer.json raise the PHP/Symfony floor at all, and is Laravel 10/11 installable without constraint overrides?Stack fit. Not a fit as a dependency; this conclusion is unaffected by v0.2.7. The only defensible path remains selective extraction — treat the repository as a reference implementation for grid configuration semantics (column metadata, filter types, sorting contracts) and rebuild the surface natively in Laravel. Budget roughly 2–4 weeks for a small team, versus open-ended integration of a minimally maintained 0.x dependency.
Migration path. If a fork is mandated, scope it tightly and now include the new feature: vendor into packages/ or a private VCS repo, drop the Symfony bundle bootstrap, pin PHP constraints to supported versions, replace the Doctrine source with an Eloquent/Illuminate\Database\Query\Builder adapter, replace Twig with Blade or Livewire, and re-target filter-state persistence at Laravel's session/request layer rather than Symfony's. Keep the framework-agnostic column and filter definition objects. Do not run Symfony's container inside Laravel.
Compatibility. Still the first wall. The 0.2.7 notes suggest incremental feature work, not a modernization pass, so assume Symfony 3.4/4.x-era and PHP 7.x constraints remain unless the manifest proves otherwise. Laravel 10/11 requires PHP 8.1+. Budget for constraint surgery, and treat a resolving composer update as a false positive until PHP 8 deprecations are cleared. Because the release line is 0.x, pin to an exact version or a commit SHA if you fork — never a caret range.
Sequencing. (1) Half-day verification of 0.2.7's composer.json, changelog, and diff to confirm whether the PHP/Symfony floor moved and whether the release is additive only. (2) One-week spike to confirm Symfony/Doctrine/session coupling and estimate extraction. (3) Parallel evaluation of Filament Tables and Livewire against the actual requirement — filter persistence is native or trivial in both, which typically terminates the ticket. (4) Only if a genuine capability gap exists, fork and extract, with filter persistence implemented against Laravel's session. (5) Ship the Eloquent adapter behind an internal interface so the grid can be swapped again without touching call sites. Gate the fork behind an ADR with a named owner.
Maintenance. You still inherit effectively all of it. The prior "no upstream" framing needs a small adjustment: there is now a live commit stream, but it is one feature in one release after a multi-year gap, with no visible security process, upgrade guide, or issue triage. Treat this as a single-maintainer, best-effort 0.x project — better than abandoned, not materially better than self-owned for planning purposes. Staff it as an internal component you will patch yourself.
Support. Still none in any contractual sense. Expect source and a README; the session-persistence option ships with whatever documentation the single commit carried. Onboarding docs remain your team's responsibility, and they now need to cover filter-state behavior and its storage semantics, not just column configuration.
Scaling. The grid is not a scaling bottleneck — it is query construction and rendering. Performance remains a function of your Eloquent adapter: unbounded filter combinations, COUNT(*) on large tables, and N+1 relationships. The new session-backed filter persistence introduces a modest, separate consideration: filter state is now per-user server-side state, which in a multi-node deployment means a shared session store (Redis/database), a serialization format you control, and a growth/eviction policy for stale saved filters. That is ordinary Laravel session work, but it is new scope that did not exist in the prior assessment and must be estimated. Mitigate query risk with indexed filter columns, capped page sizes, and explicit allowlists for sortable and filterable fields.
Failure modes.
Ramp-up. Low for engineers with prior Symfony experience (a day or two to read the grid abstractions), high for everyone else. Extraction remains a multi-week commitment competing with feature delivery, now with a small increment for re-implementing filter persistence.
TPM recommendation. Do not adopt. The v0.2.7 release is a genuine but minor liveness signal — one additive feature after a long gap — and it does not touch any of the disqualifying factors: Symfony bundle packaging, Doctrine and Twig coupling, and a 0.x release line with no support posture or compatibility evidence for PHP 8.1+/Laravel 10/11. Close the intake ticket citing the framework mismatch, and redirect to Filament Tables or Livewire, both of which cover session-persisted filter state natively or near-natively. If the requirement captures a genuinely non-commodity grid capability, fund a two-week spike to extract the configuration semantics only — not the code — and note in the ADR that upstream is a single-maintainer 0.x project to be pinned exactly and treated as forked from day one.
How can I help you explore Laravel packages today?