Aggrid Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the data grid layer. This package only wraps AG Grid — the actual grid, rendering, virtualization, filtering, grouping, and pivoting all live in the JavaScript library (AG Grid Community is MIT, Enterprise is commercial). The decision that matters is whether to adopt AG Grid as our grid standard, not whether to adopt this wrapper.
• Roadmap for internal/admin tooling. If a roadmap item is "operators need to slice large result sets (100k+ rows) with saved filters and column layouts inside the admin panel," AG Grid is a legitimate shortlist candidate. This bundle is the wrong vehicle for a Laravel codebase, but it is evidence that a thin server-side adapter is a small build.
• Framework-fit decision. The package is a Symfony bundle, not a Laravel package — no service provider, no config publishing, no Blade/Eloquent integration, no Laravel-version constraints. For a Laravel product this is a near-zero-fit dependency and should be recorded as such in the evaluation log.
• Maintenance-risk policy calibration. 2 stars, 0 dependents, last release 2020-09-10, single-vendor author. This is a useful reference case for where we draw the "unmaintained dependency" line versus the "small vendored utility" line.
• Use-case triage. Reinforces a rule we should keep: complex, stateful UI (server-side row model, infinite scroll, grouping) is a front-end architecture decision; PHP-side code should be a thin, boring JSON endpoint, not a framework-specific bundle.

When to Consider This Package

Consider it only if all of the following hold:

• You are on Symfony 4.x/5.x (pre-2020-era dependency set) and cannot easily upgrade.
• You are already committed to AG Grid on the front end and want a server-side adapter that translates grid state (sort, filter, page) into Doctrine queries.
• The integration is internal, low-stakes, and you can fork it — the codebase is small enough to vendor and maintain yourself if needed.
• You accept no upstream fixes: the last release is over four years old, so treat it as a code sample to copy, not a dependency to require.

Look elsewhere — i.e. integrate AG Grid directly — if:

• You are on Laravel. There is no Laravel integration here. The right pattern is a Blade view + a small JSON controller returning {rows, lastRow} shaped to AG Grid's server-side row model, plus a policy for auth/tenant scoping. That is roughly 1–3 days of work and removes a framework-specific dependency entirely.
• You need Symfony 6/7, PHP 8.2+, or any guarantee of security patches.
• You need support, SLAs, or a security-review paper trail. 2 stars and 0 dependents means no community to catch regressions.
• Your grid needs are simple (sortable, filterable tables under ~5k rows). Reach for a maintained Laravel table package or plain Livewire/Alpine; AG Grid's license and API surface are overkill here.
• You would be adopting it to avoid the AG Grid Enterprise license. The wrapper does not solve licensing — pivoting, grouping with server-side aggregation, and Excel export remain commercial features and should be budgeted separately.

How to Pitch It (Stakeholders)

Executives: The value in this candidate is AG Grid, a mature, widely used data-grid library — not the PHP package, which is a thin, unmaintained Symfony-only wrapper with negligible adoption (2 GitHub stars, zero dependent projects, no release since September 2020). Recommendation: do not adopt the bundle. Keep AG Grid on the shortlist for one specific need — dense, high-row-count operator tables — and treat any PHP glue as our own small, owned component. Cost avoidance is meaningful: the build is measured in days, not a vendor contract, and it stays inside our Laravel stack instead of importing a second framework's conventions.

Engineering: This is a Symfony bundle; there is no Laravel service provider, config, or Eloquent/Blade integration, so we would be pulling in framework surface area for a query-parameter translator. AG Grid speaks a simple request/response contract (startRow, endRow, sortModel, filterModel in; rowData, lastRow out), which is a controller and a query builder — work we control and can test. Plan a short spike: one representative admin table, server-side pagination and filtering, an auth/tenant scope, and a decision on Community vs. Enterprise licensing. Two risks to flag explicitly: AG Grid's major-version churn (breaking API changes between majors), and the Enterprise license cost if pivoting or Excel export enters scope. Both are front-end/commercial risks, and neither is mitigated by this bundle.