Datagrid Bundle Laravel Package

Product Decisions This Supports

• Framework fit / build-vs-buy for admin data grids. Still a Symfony bundle, not a Laravel package — release 4.0.2 does not change that. For a Laravel product the decision remains “do not adopt; define requirements and evaluate Laravel-native alternatives” (Filament, Livewire tables, Laravel Nova, or a custom query-builder + Blade component).
• Revised: legacy/modern Symfony estate triage. 4.0.2 adds Symfony 5.4 compatibility, so the candidate window widens from “Symfony 2.x only” to “Symfony 5.4 LTS estates.” This now supports a genuine fork-and-own vs. keep in-house decision for teams on 5.4 — but 5.4 is itself past bug-fix EOL (security-only), so adoption buys a short runway, not a long one.
• Roadmap scoping for internal tooling. Unchanged: use it as a requirements reference for filterable/sortable/paginated back-office tables — server-side filtering, column configuration, sorting, pagination, ORM-backed queries. Feature surface is unchanged in this patch release.
• Vendor/maintenance risk assessment. 4.0.2 is the first evidence of resumed maintenance after a stagnant period — a positive signal, but a single data point against 1 star and 0 dependents. It moves the package from “abandoned” to “alive but unvalidated,” which is still below any reasonable dependency-health gate for a revenue-critical app.
• Opportunity sizing. Unchanged at ~27/100. A compatibility patch does not create demand; it should not displace higher-leverage platform work (auth, billing, core CRUD).
• Version-line risk. The 4.x line implies a break from 3.x. Any evaluation must include a documented upgrade path and a check of what changed at 4.0.0 — the release notes here only mention framework compatibility, not migration cost.

When to Consider This Package

Consider it only when all of the following hold:

• The application is a Symfony 5.4 (or, with caveats, 2.x/3.x) codebase using Doctrine ORM and Twig.
• You need a server-side datagrid and want to avoid writing pagination/filter/sort plumbing from scratch.
• You accept vendor risk: 1 star, 0 dependents, minimal community validation, single-maintainer bus factor. The 4.0.2 compatibility release shows someone is home, but there is no evidence of a security policy, CI, or support commitment.
• You are prepared to fork and own the code — including security patching and the eventual Symfony 6/7 migration, which this release does not address.
• You have reviewed the 3.x → 4.x change set and the fork cost is genuinely lower than rebuilding the grid in-house.
• MIT licensing is compatible with your distribution model (permissive, so rarely the blocker).

Look elsewhere when:

• You are on Laravel — nothing in 4.0.2 changes this; the package is still not installable or usable without a port, and the port cost exceeds the value.
• You are on Symfony 6/7 — 5.4 compatibility is the ceiling here; use maintained grid bundles or build on modern components.
• You require active maintenance guarantees, CVE response, or a support contract — one patch release does not satisfy a dependency-health gate.
• You need exports, saved views, inline editing, or permissions-aware columns — feature coverage is unchanged by this release; assume gaps and custom work.
• Your team lacks Symfony/Doctrine depth — the bus factor cuts both ways.

How to Pitch It (Stakeholders)

Executive summary: internations/datagrid-bundle is an MIT-licensed Symfony datagrid bundle. Release 4.0.2 adds Symfony 5.4 compatibility, which is a meaningful improvement over the previous assessment — the package is no longer strictly tied to a dead framework version and shows signs of a live maintainer. It remains not a fit for our Laravel stack (still a Symfony/Doctrine/Twig bundle) and still carries negligible adoption (1 star, 0 dependents). Net: the package moved from “do not evaluate” to “evaluate only if we inherit a Symfony 5.4 estate.”

Recommendation: Do not adopt for the Laravel product — unchanged. If we need datagrid capability, run a short spike comparing Laravel-native options against a thin custom implementation, then decide. If we ever inherit a Symfony 5.4 estate, this is now a legitimate fork-and-own candidate — but only after a security review and a plan for Symfony 6/7, since 5.4 is itself nearing end of security support.

For engineering: Treat 4.0.2 as a positive maintenance signal, not a validation of the package. Any adoption still requires a named owner, a fork plan, a review of the 3.x→4.x breaking changes, and a documented upgrade path. The real cost remains maintenance and framework lock-in, not the license.