Dependent Select Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for cascading selects. Dependent dropdowns (country → region → city, category → subcategory, product → variant) recur across address forms, admin panels, and checkout. This package is a candidate shortcut for that pattern; the real decision is whether to treat cascading selects as a repeatable capability worth standardizing on.
• Build vs. buy. The bundle collapses roughly 1–3 days of form events, an AJAX endpoint, and JS wiring into configuration. Weigh that saving against owning a near-zero-adoption, effectively unmaintained dependency — and against a ~1-day in-stack implementation we control.
• Standardization decision. If dependent selects appear in more than two or three surfaces, picking one implementation beats N bespoke ones. This package is one option in that comparison; a shared in-house helper is the other, and for a Laravel codebase it is the stronger one.
• Platform reality check first. Despite the "PHP package" framing, this is a Symfony bundle, not a Laravel package — no service provider, no Blade integration, likely Doctrine ORM and older Symfony constraints. For a Laravel product, the decision is "port the idea," not "adopt the code."
• Fork provenance as a decision input. It forks evercodelab/dependent-select-bundle with 0 stars, 0 dependents, and no maintenance signal. That reframes the question from "adopt this" to "spike the upstream or build our own." The opportunity score (6.59) reflects a genuinely recurring problem; the quality score (0) reflects that this artifact is not the answer to it.

When to Consider This Package

Consider it when:

• The codebase is Symfony and already on Symfony Forms — that integration is the bundle's entire value.
• The dependent data is large or volatile enough that preloading every option in one payload is wasteful, so a genuine AJAX-driven cascade earns its keep.
• You are prepared to vendor and pin it, accept full ownership, and treat it as unmaintained code — no security advisories, no version currency, no community triage.
• Upstream evercodelab/dependent-select-bundle has already been vetted and judged acceptable; this fork adds no independent assurance over it.

Look elsewhere when:

• The project is Laravel — the form-type and DI assumptions don't carry over. Use Livewire, Alpine.js with a small authorization-scoped JSON endpoint, Filament dependent fields, or a client-side cascade library.
• Option sets are small and fixed — render them all and filter client-side; a dependency buys nothing.
• You need active maintenance, security patching, or current Symfony support — go upstream, or write the ~100 lines in-house behind our own tests.
• You need accessibility, i18n, or non-trivial validation across the cascade — bespoke implementations generally win on those requirements.

How to Pitch It (Stakeholders)

Executives: Cascading dropdowns are a low-cost, recurring pattern across our admin and checkout surfaces, and this package is a shortcut for exactly that. But the specific artifact is a zero-adoption fork with no maintenance signal, and it targets Symfony rather than our Laravel stack. Recommendation: fund a short, time-boxed spike against the upstream — or better, a ~1-day in-house implementation — rather than adopting this fork into our dependency graph.

Engineering: It supplies a Symfony form type plus an AJAX endpoint that repopulates a child select when its parent changes. The fork contributes nothing beyond upstream and carries 0 stars / 0 dependents, so any use means we own and patch it ourselves — including PHP upgrades and framework migrations. Preferred path: if we're on Symfony and upstream checks out, vendor and pin it. If we're on Laravel, implement the capability natively — a route returning {id, label}[] scoped by policy, plus 20–40 lines of Alpine or Livewire — and own it in-repo.