Grid Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/data-listing UI. The bundle provides configurable grids — columns, filters, sorting, pagination, custom fields and actions — as reusable configuration rather than hand-built index pages. For any product with a back office, that is one of the largest recurring build costs, so this is a credible "buy" (adopt) candidate versus in-house table/filter/sort code.
• Roadmap scoping for admin and reporting surfaces. New "list + filter + export" screens (orders, customers, catalog, audit logs) become configuration work rather than feature development. That shortens estimates and changes what fits in a release.
• Platform standardization decision. Adopting it establishes one grid abstraction across every admin screen, which is a governance decision (consistency, one place to fix sorting/filtering bugs) — a genuine architecture-level call, not just a library choice.
• Make-vs-extend decisions for internal tooling. The PHP GridBuilder API (introduced in the 1.11 line) means grids can be defined in code and unit-tested, so internal tools and one-off operational views can ship faster without a designer.
• Security and maintenance budgeting. The project has shipped a security release for DQL injection via sorting parameters (v1.10.1, with a follow-up BC fix in 1.10.2). That is a concrete input for your dependency-risk and upgrade-cadence planning, and evidence the maintainers respond to vulnerabilities.
• Use cases it fits: Symfony admin panels, ecommerce back offices (it is the grid layer of the Sylius stack), internal ops dashboards, CRM-style record browsers, and any screen where users expect column filters, saved sorting and pagination.

When to Consider This Package

Consider adopting when:

• Your application is Symfony (this is a Symfony bundle — it is not usable in Laravel without a port; if the team is on Laravel, stop here and evaluate an equivalent like Filament tables or Laravel Nova).
• You already have, or expect, many list/filter/paginate screens — the payback scales with the number of grids, not with a single screen.
• You are on, or can move to, PHP 8 and Symfony 5.4+, matching the 1.11+ requirements.
• You want config-first or code-first grid definitions (YAML or the PHP builder) and are comfortable with Symfony DI and service tagging.
• You are in or adjacent to the Sylius ecosystem — then this is the native choice and avoids re-solving a solved problem.
• You need Doctrine-backed listing with filters, sorting and Pagerfanta pagination out of the box.

Look elsewhere when:

• The stack is not Symfony, or the team has no appetite for bundle/DI configuration conventions.
• You need a fully-featured, batteries-included admin UI (forms, auth, CRUD scaffolding) — this is a grid/listing layer, not an admin framework.
• You need non-Doctrine or multi-source data (REST APIs, Elasticsearch-first, mixed sources) — plan for custom drivers or extra work.
• Small surface area: one or two simple tables — the integration and learning cost outweighs the benefit; a plain component will do.
• Governance constraints require broad third-party adoption signals; 134 stars and limited visible downstream usage mean you should treat the community-size signal as weak and lean on the Sylius backing instead.
• You need stable public API guarantees during migration — the 1.16 pre-releases moved builder interfaces and deprecated FQCNs, so expect some churn across minor upgrades.

How to Pitch It (Stakeholders)

One-liner: A mature, MIT-licensed Symfony bundle that turns admin list screens — columns, filters, sorting, pagination, row actions — into configuration, so we stop rebuilding the same table logic on every project.

For executives: It converts a repeated, low-differentiation engineering cost into a reusable capability. Every new back-office screen gets filters, sorting and pagination without bespoke code, which compresses delivery timelines and reduces the long tail of per-screen bugs. Cost is zero in license terms; the investment is integration time and a disciplined upgrade path. It is the grid layer behind Sylius, a commercially backed ecommerce platform, so it is not an abandoned hobby project — it has an active release cadence, current PHP/Symfony support, and a demonstrated security response.

For engineering: Symfony bundle, Doctrine + Pagerfanta based, grids declarable in YAML or via a PHP GridBuilder (testable, service-based, extensible, supports predefined fields/filters/action groups). Requirements: PHP 8+, Symfony 5.4+. Trade-offs to accept up front: it is a listing layer only — forms, auth and CRUD scaffolding are yours; the 1.16 line is actively refactoring builder interfaces with deprecation layers, so pin versions and budget upgrade time; and because sorting parameters have historically been an injection surface, keep the security patch level current.

Recommendation: Run a two-week proof of concept on two representative admin screens. Ship if the PHP builder covers our filter and permission needs and we can define a sane upgrade cadence; otherwise fall back to a thin in-house table abstraction.