Entity List Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy for admin tooling. This package represents a buy option for declarative entity listing (columns, filters, sorting, pagination) — but with zero stars, zero dependents, and an archived repository, the effective choice collapses to build (borrow the pattern) vs. buy-and-fork. There is no viable buy.
• Roadmap scoping for admin/back-office surfaces. If the roadmap contains multiple list-heavy screens (user management, order queues, audit logs, catalog administration), the pattern here — one declarative list definition per entity, compiled into a validated filtered/paginated query — is a legitimate accelerator for estimating and standardizing those screens. Decide once, apply consistently.
• Stack decision input. This is a Symfony bundle targeting Doctrine ORM, not a Laravel package. For a Laravel product this is a signal to standardize on Laravel-native listing primitives (spatie/laravel-query-builder, Eloquent scopes, cursorPaginator) rather than admitting Symfony/Doctrine into the dependency graph for a pagination feature.
• Risk posture on dependencies. Archived upstream = permanent internal maintenance ownership. This is a policy data point: does the org accept abandoned dependencies anywhere outside throwaway tooling? Here, the answer should be no.
• Feature investment framing. The reusable core is small (a few hundred lines of concept: filter allowlist, sortable columns, page-size cap, count + data query). This supports a decision to fund a small internal library or shared convention, not a porting project.
• Security/roadmap coupling. Request-driven filters and sort columns are the recurring vulnerability class in listing UIs (SQL injection via column names, DoS via unbounded page size, expensive COUNT(*)). Any roadmap item that ships list screens should carry an explicit allowlist requirement.

When to Consider This Package

Consider it only when all of the following hold:

• The target application is a contemporaneous Symfony application using Doctrine ORM, not Laravel and not a Laravel+Doctrine hybrid.
• composer.json constraints admit the project's PHP and Symfony versions (verify first — the *Bundle naming and pre-Flex packaging suggest Symfony 2/3-era code and PHP 5.6/7.x; a PHP 8.2+ target is likely a hard blocker).
• There is an existing Symfony service with several admin grids to standardize, and no Laravel-native alternative is in play.
• The team accepts forking and owning maintenance indefinitely, with a named owner, a pinned version, a committed lockfile, and a documented divergence log from the archived source.
• You are prepared to convert annotation-based filter metadata to PHP attributes and to allowlist sortable columns and cap page size yourself.

Look elsewhere — i.e. treat it as a design reference only — when:

• The stack is Laravel. Nothing installs; the bundle's wiring layer, which is most of its code, does not load.
• You need the pattern, not the code. The pattern is cheap to reimplement; resurrecting the code is not.
• You need security patches, framework upgrade paths, or any vendor support and advisory feed.
• The listing screens are customer-facing or otherwise security-sensitive and you cannot fund the review and hardening work.
• You would be the first dependent. Zero dependents means no one has proven it installs, and no community will absorb bug discovery.

Adoption criteria summary: Symfony + Doctrine + version-compatible + funded fork owner + list-heavy admin roadmap. Miss any one and the recommendation flips to reference-and-reimplement.

How to Pitch It (Stakeholders)

Executive summary. nfqde/entity-list-bundle is an MIT-licensed Symfony bundle that removes duplicated query and presentation logic from admin "entity list" screens — pagination, filtering, column definition, sorting — by letting you declare a list once and reuse it. The concept is sound and commonly reinvented. The package itself, however, is archived, has zero stars and zero dependents, and is built for a different framework than ours. It is a reference design, not an adoptable dependency.

What we recommend. Do not add it as a dependency. Fund a small, well-scoped internal capability (or adopt a maintained Laravel-native equivalent) that reproduces the pattern: one list definition per entity, compiled into an allowlisted, bounded, paginated query. Expect this to be a bounded piece of work, not a project — the reusable concept is a few hundred lines, and the porting effort for the original would exceed the value of the code recovered.

Why not just take the free code. Adoption cost is not the install; it is the ownership. Archived upstream means 100% of maintenance from day one: no security patches, no PHP or framework upgrade path, no maintainer to escalate to. Every future upgrade becomes an internal ticket, and no external community exists to find or fix the bugs we hit. The code also carries a steep reading cost — Symfony bundle config trees, compiler passes, Doctrine query-builder assembly — that a Laravel team should not acquire to solve pagination.

Risks if we did adopt it anyway. Sorting and filtering from request parameters are a known injection and denial-of-service surface (raw column names reaching ORDER BY, unbounded page sizes, expensive COUNT(*) over joins). Offset pagination degrades at depth. Lazy-loaded relation columns invite N+1 explosions. And because no test suite is guaranteed, framework drift surfaces in production — potentially as a boot-time failure across the whole service rather than a broken screen. Our own implementation must include filter allowlisting, sort-column validation, a page-size cap, and cursor pagination on large tables; those requirements hold regardless of who wrote the original.

Ask. Approve a time-boxed spike (roughly one day) to confirm the stack mismatch and inspect composer.json, then a short design note defining our list-definition contract and filter-allowlist policy. Decision gate: build the small internal capability, or standardize on an existing maintained library. Either way, name an owner and record the rationale.