Datagrid Bundle Laravel Package

Product Decisions This Supports

• Stack alignment (the first decision this forces). Despite the brief describing it as a Laravel/PHP package, freezy-bee/datagrid-bundle is a Symfony bundle. It cannot be dropped into a Laravel application without pulling in Symfony's HttpKernel/Twig/Form stack. If our roadmap is Laravel-based, this package is out of scope as a dependency and only relevant as a reference pattern. v0.5.0 ("Support SF 5") reinforces this: the maintainer's only recent investment is Symfony-version compatibility, not framework-agnosticism.
• Build vs. buy vs. fork for back-office list screens. The package addresses commodity work: configurable columns, sorting, filtering, pagination, and Twig rendering for admin tables. That is a scoping input for internal-tooling estimates (typically a sprint of generic work), not a product differentiator.
• Dependency policy / risk appetite. v0.5.0 adds Symfony 5 support — a real, if narrow, compatibility fix that removes the most common integration blocker. It does not change the underlying risk profile: still ~0 stars, 0 dependents, no visible maintainer channel or release cadence, and one release in the six-plus years since 2019-12-21. This remains a live test of whether our policy permits a single-maintainer, low-traction package in production — and it forces an explicit own-it-or-don't-ship-it decision rather than a default composer require.
• Vendor-or-depend. MIT license plus an effectively dormant upstream makes the real choice "vendor/fork this source as a starter" versus "depend on upstream." One compatibility release is a data point, not a support commitment; anyone adopting this is still taking ownership of the code.
• Admin framework selection. Adopting or rejecting this is really a decision about whether we standardize on an admin generator (EasyAdmin, SonataAdmin, Sylius Grid in Symfony; Filament, Nova, Orchid in Laravel) or keep hand-rolling grids.
• Roadmap priority. Datagrids are table stakes. This package should never appear on a roadmap as a feature; it only affects delivery cost and risk on internal tooling.

When to Consider This Package

Consider it only if all of these hold:

• The target application is Symfony 5.x (now explicitly supported as of v0.5.0) or legacy 4.x, on a PHP version that satisfies the resolved constraint set. Do not assume Symfony 6/7 or PHP 8.2+ compatibility from this release — it claims SF 5 only.
• No admin generator is in place, and the need is a fast, internal-only back-office grid.
• We accept the total cost of ownership: fork, pin, patch, and security-review it ourselves, with a named owner.
• Blast radius is small: internal users, non-regulated data, no customer-facing surface.
• The team has enough Symfony/Twig depth to debug a codebase whose last substantive work predates the current Symfony LTS.

Look elsewhere if:

• The stack is Laravel. This is not a Laravel package. Use Filament, Nova, Livewire tables, Orchid, Backpack, or yajra/laravel-datatables.
• We're on Symfony 6/7 or PHP 8.2+. v0.5.0 does not address this; constraint conflicts and unpatched deprecations remain near-certain. Use EasyAdmin, SonataAdmin, Sylius Grid, API Platform, or a small in-house grid over Doctrine's paginator.
• The surface is customer-facing, high-traffic, or security-sensitive. A single Symfony 5 compatibility commit is not a maintenance track record; any CVE or PHP incompatibility is still ours to fix, unassisted.
• Requirements exceed basics — saved views, complex exports, i18n at scale, accessibility compliance, audit trails. Buy or build instead.
• Any dependency policy requires active maintenance, an SLA, or a support contact. One release since 2019, near-zero stars and dependents, and no support channel fail all three.
• The decision hinges on a maintained upgrade path. Symfony 5 itself is past end-of-life; a package whose newest feature is "supports the version we're trying to leave" is a migration liability, not an asset.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, MIT-licensed Symfony component for rendering sortable, filterable, paginated tables in internal admin screens. It is not a Laravel package and cannot be integrated into a Laravel codebase. A new release, v0.5.0, adds Symfony 5 support — a genuine compatibility fix, but the only release since December 2019, with no community traction and no support channel. Symfony 5 is itself end-of-life, so the release narrows the integration gap without establishing a maintenance relationship. Recommendation: no-go as a dependency. For a legacy Symfony 5 back-office, at most vendor or fork it as a starter template with a named owner and a maintenance budget; otherwise standardize on a maintained admin framework.

For engineering (bullets):

• v0.5.0 is a one-line-scope change ("Support SF 5"). Treat it as unblocking a spike, not as evidence of an active maintainer. Re-verify what it actually pins in composer.json before trusting the claim.
• Value here is the pattern, not the code — the build cost of an equivalent grid is roughly one sprint, which is the real comparison point.
• If adopted, it is a fork: pin the commit, add it to the SBOM, assign an owner, and define an exit plan to EasyAdmin or an in-house grid.
• Run the version-constraint check first; if the target app is on Symfony 6/7 or PHP 8.2+, the new release does not change the answer and the spike should be cancelled.

The ask: approve a time-boxed spike to (a) confirm stack fit against the actual composer.json constraints post-v0.5.0 and (b) produce a build-vs-fork estimate — or close the question entirely if the product is Laravel-based.