Data Grid Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/back-office tables. A data grid is a recurring, low-differentiation need (sorting, filtering, pagination, column config). This package remains a candidate "buy" only on paper. The v0.2.7 release (session-based filter persistence) shows someone touched the repo, but one small feature commit does not constitute a maintenance signal. Use it as a data point in the build-vs-buy analysis, not as the answer.
• Framework fit check before roadmap commitment. Despite being filed under Laravel/PHP, this is a Symfony bundle (MakosoDataGridBundle). If your product is Laravel, it is not directly adoptable — that alone may close the evaluation. If your estate includes Symfony services, scope the decision to those services only.
• Dependency risk register. 2 stars, 0 dependents, composite score 0.14, and a release history with a multi-year gap before this one. Treat as effectively unmaintained until proven otherwise. This feeds the "unmaintained third-party dependency" policy: permit behind an internal fork, or ban outright?
• Feature scoping for back-office tooling. v0.2.7 adds an opt-in session filter save — the first sliver of the "saved views" capability the prior assessment listed as out of scope. Note the limits: session-scoped only (lost on logout/expiry, not portable across devices, not a named/shareable view, no export). Realistic scope is still simple CRUD listing views for a small internal audience.
• Opportunity signal. The 1.72 opportunity score suggests the problem space (lightweight grid tooling) has residual demand while the package shows near-zero adoption. Filter persistence being the notable addition reinforces that "remember my filters" is table stakes — an argument for building that into an in-house primitive, not for adopting this repo.

When to Consider This Package

Consider it only when all of the following hold:

• The target application is Symfony (not Laravel), on a PHP version the codebase still supports — the 2020-era baseline has not been re-verified by this release.
• The use case is an internal, low-traffic admin screen where a stalled dependency is tolerable.
• Your team is willing to vendor/fork it and own security patching and PHP-version compatibility — treat upstream as dormant despite the recent commit.
• Requirements are genuinely minimal: basic sort, filter, paginate over modest result sets, plus at most session-scoped filter memory.
• No commercial alternative fits the budget, and a 1–3 day in-house implementation is judged more expensive than a fork.

Look elsewhere (or build) when:

• The stack is Laravel — this bundle is not built for it; you would pay integration cost with no upstream support.
• You need maintained code: security advisories, PHP 8.x support, framework major-version tracking. A single feature release after a long gap is not evidence of a maintenance cadence — watch for a second and third release before revising this line.
• The surface is customer-facing, needs accessibility, CSV/Excel export, named or shareable saved views, cross-device column persistence, or performance at scale. v0.2.7's session-only filter memory does not meet a "saved views" requirement — do not let it be sold internally as one.
• You need a support contract, SLA, or vendor accountability — none exists here.
• Your dependency policy requires a minimum adoption threshold (stars, dependents, release cadence); this package still fails on every axis.

How to Pitch It (Stakeholders)

For executives: We re-reviewed a small open-source grid component for admin screens. A new version (v0.2.7) adds session-based filter saving — a minor convenience, not a maintained-product signal. It remains a Symfony bundle with two stars, zero known dependents, and a release history dominated by a multi-year gap. Recommendation is unchanged: do not adopt for anything customer-facing or long-lived. The cost of owning a fork still exceeds the cost of a small in-house component. Approve a bounded 2–5 day internal build (or budget for a maintained commercial grid) so back-office teams stop re-solving this per project.

For engineering: Treat this as a reference implementation, not a dependency. The new release is a single opt-in feature — session-persisted filters — with no indication of an ongoing maintenance plan, so nothing about patch ownership, PHP 8.x support, or framework tracking has changed. If a specific Symfony service genuinely needs it, fork it, pin the version, add it to the patch-rotation list, and cap its use to internal admin screens. Do not treat session filter persistence as satisfying a saved-views requirement; it is per-session, not per-user or shareable. Otherwise, standardize on an in-house grid primitive or an actively maintained library, and document the decision so this evaluation isn't repeated next quarter.

Framing: This is still a low-risk, near-zero-reward option, and one small release does not move it. The decision it should drive is not "adopt or don't" but "stop evaluating one-off grid libraries and pick a durable default for back-office tables."