Dependent Select Bundle Laravel Package

Technical Evaluation

Architecture fit. The most important finding for any TPM tracking this package is a category mismatch: despite the "Laravel/PHP package" framing, liz/dependent-select-bundle is a Symfony bundle — a fork of evercodelab/dependent-select-bundle. It assumes Symfony's DependencyInjection container, the symfony/form component, the EventDispatcher, and in all likelihood Doctrine ORM entity repositories to resolve child options. None of that maps to a Laravel application. There is no service provider, no facade, no publishable config, and no Blade integration. The capability it implements — a parent <select> whose value triggers an AJAX call that repopulates a dependent <select> — is real and recurring; the artifact is not a Laravel component.

Integration feasibility. Low as-is, moderate as a concept. In a Laravel codebase, the realistic path is to port the pattern, not the code: a small controller returning JSON keyed on parent_id, a seeder/mapping table for (group, parent, child) tuples, and ~20–40 lines of Alpine/Livewire/Vue to fire on change. That is roughly 1–3 engineering days and yields code we own, test, and can extend for accessibility and i18n. A literal integration would require running Symfony alongside Laravel (a sidecar service or a full framework addition) — an architecture change, not a dependency addition.

Technical risk. High:

• Abandonment. 0 stars, 0 dependents, single-user fork of an unmaintained upstream. Almost certainly cut for one specific application; no release cadence, no issue triage, no security patching.
• Version rot. Upstream targets the Symfony 2.x/3.x era with likely PHP 5.x–7.x constraints. That fails Composer resolution against Laravel 10/11 (PHP 8.1+) and Symfony 6/7.
• Coupling. Doctrine ORM is a probable hard dependency — a philosophical and technical conflict with Eloquent.
• Supply chain. An unmaintained, low-visibility fork is exactly the profile Composer security audits and malware scanners flag.

Key questions.

1. What PHP/Symfony versions does the fork pin in composer.json, and does it still require doctrine/orm?
2. Was the fork made to patch a specific bug or constraint? Is there any diff vs. upstream, or is it a verbatim snapshot?
3. Is the consuming product actually Laravel or Symfony? The answer changes the decision entirely.
4. Do we need bundle-level cascading-select plumbing, or just a reusable AJAX-driven form pattern (already available via Livewire/Filament/select2 AJAX)?
5. Why does the opportunity score (6.59) diverge so sharply from the quality score (0)? The niche is real; this artifact is not the answer to it.

Integration Approach

Stack fit. Poor for Laravel; acceptable only if the consuming application is Symfony. Laravel + Symfony bundle is a host/framework boundary violation. Even in a Symfony shop, this fork is a liability versus the upstream or a hand-rolled ChoiceType extension with real maintenance.

Migration path. Do not migrate the package — migrate the capability:

1. Define the contract: parent field → GET /api/options/{parentId} → [{id, label}].
2. Implement the endpoint in Laravel (thin controller + Eloquent where('parent_id', $id)), scoped by authorization policy.
3. Implement the client behavior with Alpine.js or Livewire — small, testable, owned in-repo.
4. If Symfony interop is genuinely required, isolate it behind a service boundary; do not import the bundle into the Laravel app.
5. Where the mapping is large, generate the pair table (e.g., country → region → city) from real domain data via a seeder, and treat it as a rebuildable cache rather than a source of truth.

Compatibility. Assume incompatible until proven: expect PHP ≤ 7.4 and Symfony ≤ 3.4 constraints, plus a Doctrine ORM requirement. Any Laravel 10/11 target will fail dependency resolution. jQuery-era front-end assets in Resources/public/js/*.js are another integration tax in a modern asset pipeline.

Sequencing. (a) Confirm framework reality — Laravel or Symfony? (b) Confirm the requirement is real and not already covered by an existing form/UI component. (c) Spike the in-house AJAX/Livewire pattern (1–2 days). (d) Only if that spike fails, revisit third-party options with active maintenance. (e) Gate any new dependency through license and security-audit review before merge.

Operational Impact

Maintenance. Effectively zero external maintenance. Ownership transfers entirely to the adopting team at the moment of use — including security patches, PHP upgrades, and framework migrations. For an artifact with 0 stars and 0 dependents, plan on no upstream help and no changelog to rely on.

Support. Community-only, and in practice no community. No vendor, no SLA, no documented support channel. Internal runbooks and source-reading will be the primary support mechanism; budget time for an engineer to reverse-engineer form option names and the AJAX route contract.

Scaling. Not a scaling concern for the cascade itself — it is a client-side behavior plus a small indexed lookup. The real risks are unindexed parent_id lookups on large reference tables, N+1 queries if options are resolved per rendered row, and unbounded result sets returned to a <select>. Mitigate with a composite index on (group, parent_id), pagination or typeahead for large child sets, and short-TTL caching of reference data.

Failure modes.

• Composer install fails on PHP 8+ / Laravel 10+ (constraint conflict).
• Doctrine ORM vs. Eloquent DB layer conflict if bridged directly.
• Silent behavior drift if the fork diverges from upstream with no diff trail.
• Security exposure from an unmaintained dependency in a production lockfile.
• Data leakage if the AJAX option endpoint is not authorization-scoped — child options can reveal records the user should not see.
• Edit-form re-render bugs where a parent value is preset but the child options are not repopulated server-side.

Ramp-up. For a Symfony-fluent engineer, hours to understand the bundle. For a Laravel team, high friction — they would be learning foreign framework idioms to maintain a foreign dependency for a feature that is a day's work natively. Net recommendation: do not adopt this fork; reimplement the capability in-stack. The opportunity signal (6.59) is worth noting for a build-vs-buy decision, but this artifact scores 0 for good reason and should not enter the dependency graph. If the team is on Symfony and wants the shortcut, evaluate the upstream evercodelab/dependent-select-bundle directly — this fork adds no independent assurance.