Eloquent Param Limit Fix X Laravel Adjacency List Laravel Package

Product Decisions This Supports

• Framework-upgrade gating (the only real decision v1.4 touches). This release is a compatibility change and nothing more: it adds Laravel 13 support to a bridge between eloquent-param-limit-fix and laravel-adjacency-list. For any roadmap item blocked by a Laravel 13 upgrade in a product that stores hierarchical data — category trees, org charts, threaded comments, nested navigation, BOM/parts structures — this package is a named prerequisite. Without it, Composer resolution fails; with it, the blocker disappears. Treat it as a line item on the upgrade train, not a feature.
• Committing (or not) to recursive-CTE adjacency lists as the tree strategy. Adopting this package is an implicit architectural statement: our hierarchies are modeled as adjacency lists queried via recursive CTEs, not nested sets (kalnoy/nestedset), closure tables, or materialized paths. If that call is already made, the bridge is the natural consequence. If it is still open, a PM should ask why this package is in the dependency graph at all — it silently answers a schema question that deserves an explicit owner.
• Build vs. buy for the "glue" layer. This is a thin, single-purpose shim maintained by the same author as both parents, resolving trait/query-builder conflicts between parameter-chunking logic and the adjacency-list builder. Writing and owning that shim in-house is low-value work; buying it via Composer is obvious, and the fork contingency is roughly one class. Fund it as maintenance, not as a feature investment.
• Database portability as a stated product requirement. The parent eloquent-param-limit-fix exists because SQLite (~999 bind parameters) and SQL Server (2,100) break on large whereIn sets, while MySQL/Postgres have far more generous ceilings. "Runs anywhere" — SQLite for local dev and CI, Postgres or MySQL in production, SQL Server in enterprise — is a promise this package helps keep specifically for tree queries. A PM who has committed to that promise should know this is part of the mechanism.
• The scale envelope for hierarchy features. Deep or wide trees generate large parameter sets. This package keeps "render a five-level category tree with per-node counts" or whereDescendantOfMany() over thousands of IDs viable without hand-tuned batching or denormalization. But understand the trade: it converts a hard failure into additional round trips, so query count and latency grow roughly linearly with chunk count. Instrument tree endpoints for query volume, not just correctness — the fix can mask a design that should be batched or denormalized upstream.
• Maintenance/compatibility debt, explicitly tracked. v1.4 adds no customer-visible capability. It should be a standing line item on every Laravel major and every upstream major: budget a recurring dependency-matrix review rather than an owner. The realistic contingency — vendoring or forking at short notice — should be a documented option, not an improvisation during an incident.

When to Consider This Package

Consider it when:

• You use both staudenmeir/laravel-adjacency-list and staudenmeir/eloquent-param-limit-fix in the same application, and tree queries throw parameter-limit or binding-count errors. The bridge is load-bearing only under that conjunction.
• You target multiple database engines — particularly SQLite in test/CI or SQL Server in enterprise deployments — and have non-trivial hierarchy depth or width.
• You are planning a Laravel 13 upgrade and need the dependency graph framework-ready. v1.4 is precisely that signal; pin it in the same changeset as the framework bump, because a Laravel 13 upgrade without it fails resolution.
• You want the smallest possible maintenance surface: single-purpose bridge, maintained by the upstream author of both parents, near-zero integration effort (composer require; no service provider, no migrations, no config publishing). Verify the trait swap — replacing HasAdjacencyList with the bridge's exported trait is the entire integration surface.

Look elsewhere when:

• You use only one of the two parent packages. The bridge is dead weight.
• Your hierarchies are shallow and whereIn cardinality stays well under engine ceilings (roughly <999 on older SQLite; tens of thousands on MySQL/Postgres depending on configuration). Benchmark the largest tree per driver before assuming the fix is load-bearing.
• You have chosen a different tree representation (nested set, closure table, graph database). This package is irrelevant to that architecture.
• You need active feature development, SLAs, or security-review artifacts. This is a single-maintainer compatibility shim; expect releases that track upstream majors and little else.
• SQLite/SQL Server appear only in dev/CI and never in production — then judge it as a test-fidelity dependency, not a production one.

Constraint hygiene. The bridge must stay version-aligned with both parents. Treat laravel-adjacency-list, eloquent-param-limit-fix, and this bridge as a single upgrade unit, resolve them together (composer update <bridge> <adjacency-list> <param-limit-fix> -W) to avoid partial-upgrade dead-ends, and confirm supported ranges in composer.json rather than relying on release notes. Introducing a fourth staudenmeir package can render resolution unsatisfiable. Two questions to get answered before sign-off: does v1.4 widen the upstream constraints (safe) or pin them to a specific parent pair (forces lockstep upgrades), and do we actually have a tree query that crosses a parameter ceiling today?

How to Pitch It (Stakeholders)

To executives: This is a low-risk, low-cost compatibility update. It changes no product behavior — it keeps an existing internal capability (hierarchical data such as category trees, org structures, and comment threads) working on the newest Laravel version. Its practical value is unblocking the Laravel 13 upgrade for any module that stores tree-shaped data. Cost and risk are both negligible. The only notable consideration is that maintenance sits with a single upstream maintainer, which is acceptable at this scope and mitigable by forking a one-class shim. Fund it as maintenance, not as a feature.

To engineering: v1.4 adds Laravel 13 support to the bridge that lets eloquent-param-limit-fix and laravel-adjacency-list coexist. Without it, adjacency-list's custom query builder bypasses the parameter-chunking traits, so deep- or wide-tree queries can exceed placeholder limits — typically surfacing as binding-count errors on SQLite in CI and on large whereIn sets on SQL Server. Action items: inventory which services import adjacency-list and on which drivers; confirm the ceiling is actually reachable (staging test with >999 nodes on SQLite); include the bridge in the Laravel 13 upgrade train and bump it together with both parent packages; verify the resolved version ranges in composer.json; and monitor query volume on tree endpoints, since the fix trades a hard failure for additional round trips. No application code changes are required beyond the trait swap, if that has not already been done.

To the product/roadmap audience: Treat the triple (bridge + both parents) as one line item. Patch-level from v1.3 to v1.4, zero application changes, re-run the tree-query tests. Prove the limit is reachable before committing to this as a production dependency — otherwise call it what it is: test-fidelity insurance. And name it as a prerequisite in the same release train as the Laravel 13 upgrade, so the upgrade does not stall on an unowned dependency.