Dependent Select Bundle Laravel Package

Technical Evaluation

Architecture fit — the premise itself is the first finding. The brief classifies kabuto/dependent-select-bundle as a Laravel/PHP package; it is a Symfony bundle. From a TPM's standpoint this is the evaluation's headline, not a footnote: the work item as scoped ("assess this package for our Laravel app") is unresolvable as an adoption, and the deliverable a TPM actually owes is a decision record, not a trial integration. A Symfony bundle is a full-stack construct — a Bundle class registered with the kernel, a DI Extension and Configuration tree, compiler-pass service tags, and bundle-owned routing resources. Laravel has no consumer for any of that. Laravel's shared use of Symfony components (HttpFoundation, Console) does not make it a Symfony application, and the distinction is the one that matters here.

Integration feasibility — zero as a drop-in; moderate as a reference. Realistic cost to attempt a direct install is unbounded (dependency resolution failures, platform-requirement workarounds, runtime breakage), and the realistic yield is a non-working form stack. The asset that survives the fit check is the pattern: a JSON endpoint that maps a parent value to a filtered child set, a form-layer hook that populates and validates the child server-side, and a small front-end controller that swaps <select> options. That pattern is portable to any stack in one to three engineer-days.

Technical risk — dominated by provenance, not by code.

• No ecosystem signal. 0 stars, 0 dependents, 0.03 composite. For a form-input package — security-adjacent by definition — zero dependents means zero downstream hardening. The prior should be abandonment.
• Framework-era drift. The bundle naming and vendor style point at Symfony 2.x/3.x. Expect PHP 5.x-era platform constraints that would force --ignore-platform-reqs against Laravel 10/11 (PHP 8.1+). That is a stop sign, not a workaround.
• Doctrine coupling. Cascading-select logic of this vintage is typically configuration-driven against Doctrine entity repositories — Eloquent-incompatible independent of the framework question.
• Endpoint surface as attack surface. A generic "resolve children for field X" controller is where enumeration and unconstrained-query bugs live. Worth reading even as reference code; not worth inheriting.
• License unverified. Since the realistic path is code reuse as a template, the license is a gating item, not a footnote.

Key questions to close before any decision:

1. composer.json constraints on php and symfony/*, and last commit date — does it run on a supported stack at all?
2. License — permissive enough for derivative reuse as a template?
3. Is the data source abstracted behind an interface, or hard-wired to Doctrine?
4. Is the AJAX endpoint authenticated, and does it whitelist which parent fields may be queried?
5. Does the JS depend on a specific form theme or jQuery version?

The expected disposition on answers is reject as a dependency, retain as a 30-minute reference read.

Integration Approach

Stack fit — none directly; the analogues are named for the TPM to route. If the target is Laravel, the stack-native options are Livewire (wire:model.live on the parent + computed child options), Inertia with a scoped JSON endpoint, or an Alpine.js component hitting a named route. Each is idiomatic, supported, and — critically for a TPM — has a maintenance owner inside the team. Choosing among them is an engineering call, but the TPM should force the choice to be explicit and recorded rather than defaulting to "port the Symfony thing."

Migration path — there is nothing to migrate. With zero dependents, the package is not in production anywhere in the estate. The path is a build, using the source as a specification:

• One route — GET /api/options/{field} — with a whitelist map of field → query, returning [{value, label}].
• One Blade partial or JS module to repopulate the child select and clear stale child selections (a correctness requirement users notice).
• Authorization and validation on the field parameter.
• Server-side re-validation of the parent-child pairing on submit; a client-side cascade alone is a data-integrity hole.

Compatibility. Any lifted snippet must pass the same static analysis, CS, and test gates as first-party code — no exemptions because it arrived via Composer. Pin PHP and Laravel versions explicitly in the decision record so a future reader knows what was validated against.

Sequencing — TPM owns the first three steps, engineering owns four and five.

1. Day 0 (30 min): inspect composer.json, license, last commit, controller and repository code. Close the decision.
2. Decision record: document the rejection with the framework-mismatch rationale so this does not get re-proposed by someone who saw the star count and assumed it was evaluated.
3. Scope the real requirement: how many cascade levels, are option sets tenant-scoped or permission-filtered, is no-JS/accessibility parity required? These dominate the estimate and none are solved by a minimal bundle.
4. Spike: thinnest version of the pattern in the target stack against one real cascading form.
5. Generalize only if a second and third dependent field actually materialize — resist approving a generic resolver on speculation.

Operational Impact

Maintenance. Adoption means vendor-fork ownership: you patch a package with no upstream, forever, against a framework it was never written for. Building in-house means owning ~100 lines the team fully understands. Total cost of ownership is strictly lower for the build — this is the argument the TPM puts in front of a review board that asks "why not just use the package?"

Support. No vendor, no issue-tracker activity, no release cadence, no security advisory feed. A CVE in the dependency surfaces only through the team's own scanning with no upstream fix to pull. Combined with the fact that form code touches user input, this is the dominant reason to reject.

Scaling. The pattern scales — cached option lookups, indexed parent foreign keys. The bundle's implementation may not: a per-change AJAX endpoint hitting an unindexed Doctrine repository is the classic failure mode in this package class. Before copying the design, confirm N+1 behavior and whether responses are cacheable.

Failure modes a TPM should track as risk register items.

• Silent breakage on PHP/Laravel upgrade with no upstream to fix it.
• Unbounded queries if the parent-field parameter is not whitelisted.
• Stale child selections after a parent change — a visible correctness bug that support will absorb.
• --ignore-platform-reqs installs that appear to work and fail at runtime.

Ramp-up. Negligible either way — the codebase is readable in an afternoon. That cuts both ways: cheap to learn and cheap to reimplement, which is precisely why the adoption case does not close. For a TPM, the practical ramp cost is the review cost, not the learning cost: one engineer-day of security and provenance review to reach a rejection that framework fit already dictated.

Bottom line for the decision. Reject as a dependency on framework-fit grounds alone; the health signals (0 stars, 0 dependents, 0.03 score) independently reinforce it. Retain as a short reference read for the endpoint + form-listener + JS pattern, log the decision, and fund the in-house build under the existing cascading-forms epic — not as a new initiative.