Entity List Bundle Laravel Package

Technical Evaluation

Architecture fit. The decisive fact for a TPM is that nfqde/entity-list-bundle is a Symfony bundle targeting Doctrine ORM, not a Laravel package. It relies on bundle registration (config/bundles.php / AppKernel), Symfony’s DI container and config-tree extensions, a Symfony Request for filter/sort/paging parsing, and Doctrine QueryBuilder assembly. A standard Laravel application has none of those seams: no bundle lifecycle, no Doctrine by default, and Eloquent rather than ORM entities. Even on a Laravel + Doctrine hybrid stack, the majority of the package’s code — the Symfony wiring layer — is what you would be installing and not using. Verdict: not adoptable as a Composer dependency in a Laravel application; viable only inside a contemporaneous Symfony/Doctrine service. For Laravel, the value is the pattern, not the code.

Integration feasibility. Low. Zero stars, zero dependents, and archived status mean there is no downstream evidence of a clean install against any supported framework version, and no upgrade path. The reusable core — a declarative list definition (columns, filters, sort order, page size) compiled into a filtered, paginated query — is small and well understood. A TPM should frame the choice as fork-and-port vs. reimplement: the port carries Symfony bundle fluency and Doctrine-era constraints; the reimplementation is a bounded, testable piece of work on the team’s native stack. The MIT license is the one clean signal — forking and internal maintenance are legally unencumbered, which removes the licensing question from the decision.

Technical risk.

• Abandoned upstream. Archived means no security patches, no PHP/Symfony/Doctrine compatibility updates, no advisory feed. Every transitive Doctrine CVE becomes an internal ticket from day one.
• Era mismatch. The *Bundle naming and pre-Flex packaging strongly suggest Symfony 2/3-era code with PHP 5.6/7.x constraints. Treat PHP 8.2+ compatibility as unproven until composer.json is read.
• Request-driven query surface. Filter keys, sort columns, and page size arriving from the query string are the classic failure vector: unvalidated sort/filter columns reaching ORDER BY/WHERE (schema leak, SQL injection) and unbounded page sizes (DoS, connection-pool exhaustion).
• Count/result divergence. COUNT(*) over joined, filtered queries routinely disagrees with the returned rows; totals are a user-visible correctness issue, not a cosmetic one.
• N+1 exposure. A generic list query does not fetch-join relations displayed as columns; grid columns backed by lazy-loaded relations become per-row queries at production scale.
• Opaque quality. No test-coverage signal, no issue history to learn from, no maintainer to escalate to.

Key questions (for the decision record).

1. Is the target application actually Symfony/Doctrine, or Laravel? This changes the recommendation — but archived status applies either way.
2. What do composer.json constraints and the last commit date say about PHP/Doctrine/Symfony compatibility with our runtime?
3. Do we need the abstraction (declarative entity lists) or this implementation? The abstraction is cheap to rebuild; the code is expensive to resurrect.
4. Are filter keys and sortable columns allowlisted, and is page size bounded?
5. Is there an internal NFQ fork already in production that de-risks adoption, and who would own a fork?
6. What is the budget for a replacement path, and by when?

Integration Approach

Stack fit. For a Laravel product, the correct posture is do not integrate; borrow the design. The package defines a useful contract — one list definition per entity declaring selectable columns, filter definitions, sortable fields, default page size, and paging metadata — and that contract is the durable asset. Three postures, in descending order of preference:

1. Design reference only. Reimplement the list-definition concept natively. Laravel-idiomatic building blocks: spatie/laravel-query-builder for allowlisted filter/sort/include parsing, Laravel’s paginator/cursorPaginator, Eloquent local scopes or a ListDefinition value object per entity, and a single controller action per list.
2. Thin internal package. If the pattern recurs across many admin screens, invest once in an internal entity-list package exposing the same contract (definition → validated query → paged payload). This is the right home for the shared policy: filter allowlists, page-size caps, sortable-column allowlists.
3. Fork and port. Only if a genuine Symfony/Doctrine service already needs the functionality — and then adopt it there, not in Laravel. Even in that case, the archived status argues for pinning and owning it deliberately.

Migration path. There is no migration from this package into Laravel, because nothing installs. The realistic path is a greenfield reimplementation of the abstraction. Copy the concept, not the code: define a ListDefinition per entity (fields, allowed filters, sortable columns, page-size cap), compile it to a query builder, and expose it through one controller with validated query parameters. Expect this to be small and bounded — days, not a project — which is precisely why the TPM recommendation is to build rather than port.

Compatibility. Treat as unverified until composer.json is read. Assume PHP ≤ 7.x and Doctrine 2.x semantics (string QueryBuilder, annotation-based filter metadata, no attributes, no DBAL 4). If those constraints exclude our runtime, discard the fork option immediately and stop spending evaluation time on it. Note the annotation angle specifically: doctrine/annotations deprecations/removal would force a fork that converts annotations to PHP attributes before the package runs on modern PHP at all.

Sequencing.

1. Classify (0.5 day). Read composer.json, README, and last-commit date; confirm framework era and PHP constraints.
2. Decide and record (0.5 day). Choose adopt / borrow / build; write the rationale into the ADR so it isn’t relitigated next quarter.
3. If borrowing: write a one-page design note. Define the ListDefinition contract, the filter/sort allowlist policy, page-size cap, and the paging response shape (rows + total + applied filters).
4. Implement on the Laravel stack. One list class per screen — no god-lists. Keep construction behind a factory/service (e.g. UserListFactory) so the seam for swapping implementations survives.
5. Test the policy, not just the happy path. Filter allowlisting, sort-column validation, page-size bounds, empty-result behavior, and count/rows agreement with joins applied.
6. Security review the exposed endpoints before they reach any non-admin surface.
7. Only then consider whether a downstream Symfony service should standardize on the original package — the archived status argues against it.

Operational Impact

Maintenance. Archived upstream means the adopting project owns 100% of maintenance from day one: every PHP minor, Symfony major, and Doctrine major is an internal ticket, and with zero dependents no external community shares that work. A fork is a permanent line item, not a one-time integration cost. The reimplementation posture avoids this entirely — the code lives on the team’s own stack, with the team’s own upgrade cadence.

Support. No vendor, no SLA, no advisory feed, no maintainer to escalate to. If a fork is created, the internal owner must be named explicitly and the provenance documented (source commit, divergence log, patch queue, pinned versions) so a future engineer can reconstruct intent. Commit composer.lock, pin exact versions (x.y.*), and state an intended replacement date.

Scaling. Listing and filtering is the canonical admin-panel scaling problem, and the package’s likely approach — offset pagination with COUNT(*) over filtered joins — degrades predictably:

• Deep offsets get slower linearly; move high-volume tables to keyset/cursor pagination.
• COUNT(*) over filtered joins is often the dominant cost; cache or approximate.
• Unindexed filter/sort columns cause full table scans — only expose columns that have supporting indexes.
• Join-based display columns multiply rows and invite N+1 unless fetch-joined.

Failure modes.

• Unbounded page size or arbitrary filter keys → slow queries, pool exhaustion, database timeouts.
• Raw column names from request parameters → SQL injection.
• Lazy-loaded relation columns → N+1 explosion as list length grows.
• Count/result mismatch when the count and data queries are filtered inconsistently.
• Silent breakage on a PHP/Doctrine upgrade, discovered in production because there is no upstream test suite to catch it.
• Careless porting puts config/DI errors at boot rather than at the call site — a whole-service outage instead of one broken screen.

Ramp-up. The concept — define columns/filters/sort, paginate, render — is learnable in an afternoon; conceptual ramp-up is negligible. Code-level ramp-up is the problem: reading the source requires Doctrine and Symfony-bundle fluency (config trees, compiler passes, query-builder assembly) that a Laravel team neither has nor should acquire for this purpose. Net assessment for the TPM: the code carries a steep reading cost relative to a small conceptual payload, which reinforces the recommendation — borrow the pattern, keep the implementation on our own stack, and spend the saved effort on the allowlist and paging policy that actually protects production.