Dependent Select Bundle Laravel Package

Product Decisions This Supports

• Stack-fit gating as a standing evaluation step. kabuto/dependent-select-bundle is a Symfony bundle, not a Laravel package — no service provider, no config file, no publishable assets, and no adapter path. The most important decision it supports is a rejection: it validates a policy that framework fit is checked before any feature-level evaluation begins.
• Build vs. buy (vs. read-and-rebuild). With 0 stars, 0 dependents, a 0.03 score, and no maintenance signal, the rational call is to build in-house (~1–3 engineer-days for a single dependent pair) or adopt a stack-native approach (Livewire wire:model.live + computed options, or Alpine/Inertia hitting a JSON route). Its real value is as a reference implementation of the pattern, not a runtime dependency.
• Feature prioritization: commodity UX, not differentiation. Dependent/cascading selects (country → region → city, category → subcategory, plan → add-on) are table stakes. This belongs inside an existing forms epic, not on the roadmap as a standalone item.
• Use-case scoping. Address capture at checkout/onboarding, admin CRUD with parent-child entities, catalog filtering — anywhere a second field's option set is a function of the first field's value.
• Dependency governance calibration. A useful test case for a third-party adoption scorecard: stars, dependents, release cadence, framework-version support, test coverage, security disclosure, license. Zero dependents on form-handling code — which touches user input and is security-adjacent — is a meaningful negative signal.
• Hidden scope multipliers to plan for. Three-plus cascade levels, multi-tenant scoping of option sets, permission-filtered options, searchable/typeahead selects over large datasets, and no-JS/accessibility fallbacks are not solved by a minimal bundle and will dominate real effort.

When to Consider This Package

Consider it only if all of the following hold:

• The target application is Symfony (not Laravel) and on a version compatible with the bundle's form-event API.
• The need is a simple, single-level dependency — one parent field driving one child field.
• The dataset is small enough that a synchronous AJAX fetch per change is acceptable.
• It is a short-lived internal tool or prototype where long-term maintenance is not a factor.
• You are prepared to vendor/fork and own the code, since there is no realistic upstream support path.

Look elsewhere — or build — if any of these are true:

• You are on Laravel. Hard stop. Use Livewire (wire:model.live + computed child options), Inertia + Vue/React, or a plain scoped JSON endpoint with an Alpine.js/Stimulus controller.
• You need more than two levels of cascading, or one parent fanning out to multiple dependent fields.
• You need searchable selects, virtualized lists, or thousands of options — an AJAX-per-change model degrades badly.
• You need accessibility guarantees (ARIA live-region announcements on option changes) or progressive enhancement without JS.
• The feature is customer-facing and long-lived; a 0-star, 0-dependent dependency in a revenue path is an unacceptable bus-factor risk.
• You require security review, CVE monitoring, or an SLA — none exist here.
• You need server-side validation parity: the parent-child relationship must be re-validated on submit (e.g., exists:children,id,parent_id,{parentId}). A client-side cascade alone is a data-integrity hole.

Questions to close out before any decision: composer.json PHP/Symfony constraints and last commit date; license (MIT or restrictive, since the realistic outcome is template reuse); whether it couples explicitly to Doctrine; whether the AJAX endpoint is authenticated and whitelists which parent fields may be queried; and whether the JS depends on a specific form theme or jQuery version.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated kabuto/dependent-select-bundle for cascading form fields and recommend not adopting it. It is a Symfony-only bundle with no community traction (0 stars, 0 dependents), no maintenance signal, and — decisively — it does not run on our Laravel stack. The capability it provides is commodity form UX, not a differentiator, and building it ourselves is roughly one to three engineering days with full control, test coverage, and security review. Taking an unmaintained third-party package into a user-input path would create ongoing bus-factor and security risk for no offsetting gain. Recommendation: build in-house using stack-native tooling (Livewire or Alpine + a scoped JSON endpoint), and reuse this package only as a design reference for the parent-child form pattern.

To engineering (summary): Treat this as a pattern reference, not a dependency — the framework mismatch alone rules out direct integration, and the health signals independently reinforce it. The pattern to implement: a whitelisted JSON route that returns child options for a given parent ID, server-side population and validation of the child field, and a small front-end controller that swaps the child <select> on parent change and clears stale selections. Build it with Livewire or an Alpine component hitting an authorized, scoped route. Non-negotiables: server-side re-validation of the parent-child pairing on submit, authorization on the option endpoint so we don't leak another tenant's taxonomy, request debouncing and in-flight cancellation, a loading state, and an ARIA live region announcing the updated option count. Budget the extra effort for three-level cascades and tenant-scoped option sets — those are the real cost drivers, and no minimal bundle solves them. Document the rejection rationale in a decision record so it isn't re-proposed.