Dependent Select Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on dependent-field UX. Every form with a parent/child relationship (country → region → city, category → subcategory, product → variant, plan → add-on) forces the same decision: hand-roll the AJAX wiring, adopt a package, or accept a worse UX (full page reload). This package is a data point in that decision, not the decision itself.
• Roadmap prioritization for form-heavy surfaces. If dependent selects appear in onboarding, checkout, or admin CRUD, the pattern is worth standardizing once; if they appear in one low-traffic internal screen, it isn't. The package's existence argues that the pattern is common enough to have a house convention.
• Framework-strategy validation. Despite being filed under "Laravel/PHP," this is a Symfony bundle (EvercodeLab/DependentSelectBundle) and is not installable in Laravel. It has zero dependents and no meaningful stars — treat it as a reference implementation of a pattern, not a candidate dependency. The real product decision is "what is our house pattern for cascading selects in our stack?"
• Vendor-risk policy calibration. A package with no stars, no dependents, and no visible maintenance is a useful test case for whether the team has (and enforces) a minimum bar for third-party adoption. If this would pass review, the bar is too low.
• Use cases worth scoping: geo hierarchies, taxonomy pickers, SKU/variant builders, pricing configurators, permission/role trees, and any admin filter panel with chained selects.

When to Consider This Package

Consider the pattern (not the dependency) when:

• You are on Symfony and want to see one concrete way to wire a form type to an AJAX endpoint that returns filtered options.
• You need a short, readable reference for the server contract (parent value in → filtered option list out) before writing your own.

Look elsewhere — and almost certainly write it yourself — when:

• You are on Laravel. This bundle is not compatible. The Laravel equivalents are Alpine.js + a small JSON endpoint, Livewire wire:model.live cascades, Inertia + a scoped query, or Filament's ->live() / ->options() reactive fields. Any of these is a few dozen lines.
• You are on modern Symfony. Symfony UX Live Components and EntityType with a query builder cover this natively; the bundle's era and API surface likely predate them.
• Dependency hygiene matters. Zero stars, zero dependents, and an unmaintained-looking bundle is a supply-chain and upgrade liability (framework major-version bumps, PHP version bumps). The functional core is small enough that vendoring code you don't control costs more than writing code you do.
• You need accessibility, i18n, caching, or debounce/race-condition handling. These are the hard parts of cascading selects, and a thin bundle won't solve them.

Adoption criteria if you insist on evaluating it: active commits in the last 12 months, a supported Symfony/PHP version matrix in CI, tests, a documented client-side contract (debouncing, empty-state, error handling), and a security review of the endpoint (authorization on the child-options query — a common and serious bug class in these implementations).

How to Pitch It (Stakeholders)

To executives: A small third-party bundle surfaced for cascading dropdowns. It doesn't fit our stack, and it's effectively unmaintained — adopting it would trade a two-day build for an open-ended maintenance and upgrade risk. Recommendation: don't adopt; build the pattern in-house, roughly 1–2 engineering days, and reuse it across every form that needs chained fields.

To engineering: This is a Symfony bundle, not a Laravel package, so it's out of scope as a dependency. Its only value is as a design reference: a form type plus an endpoint that returns filtered options for a given parent value. Our house implementation should use the framework-native reactive layer (Livewire/Alpine/Filament or Symfony UX), and must include the things a bundle like this typically omits: authorization on the child-options query (never trust the parent ID), debouncing, request cancellation for out-of-order responses, accessible loading and empty states, and caching of static hierarchies.

Net recommendation: Reject as a dependency; harvest as a pattern. The cost of writing this ourselves is low and bounded; the cost of owning an abandoned bundle is neither.