- Does kabuto/dependent-select-bundle work with Laravel?
- No. Despite being distributed on Packagist as a Composer package, it is a Symfony bundle, not a Laravel package. A Symfony bundle relies on a Bundle class registered with the Symfony kernel, a DI Extension with a Configuration tree, compiler passes, and bundle-owned routing resources. Laravel has no consumer for any of that, so there is no drop-in path to adoption. Laravel sharing Symfony components such as HttpFoundation and Console does not make it a Symfony application.
- Can I just run composer require kabuto/dependent-select-bundle in a Laravel app?
- You can attempt it, but expect dependency resolution failures and platform-requirement conflicts. The bundle naming and vendor style point to the Symfony 2.x/3.x era, which means PHP 5.x-era constraints that would force --ignore-platform-reqs against Laravel 10 or 11 on PHP 8.1+. Even if installation succeeded, you would end up with a non-working form stack. Treat any platform-requirement workaround here as a stop sign, not a valid integration path.
- What is the Laravel equivalent of DependentSelectBundle for cascading dropdowns?
- The idiomatic Laravel options are Livewire with wire:model.live on the parent field and computed child options, Inertia paired with a scoped JSON endpoint, or an Alpine.js component hitting a named route. Each is supported, idiomatic, and has a maintenance owner inside a typical team. The important thing is to make the choice explicitly and record it rather than defaulting to porting the Symfony bundle.
- Which PHP and Symfony versions does this bundle support?
- Based on the bundle naming, vendor style, and era, it most likely targets Symfony 2.x or 3.x with PHP 5.x platform constraints. The exact answer lives in the composer.json require block for php and symfony/*, along with the last commit date. Check both before spending any time on it; if the constraints predate PHP 8.1, it cannot run on a currently supported Laravel stack.
- Is kabuto/dependent-select-bundle actively maintained?
- There is no ecosystem signal at all: zero stars, zero dependents, and a 0.03 composite score. For a form-input package, which is security-adjacent by definition, zero dependents also means zero downstream hardening. The reasonable prior is abandonment, so plan accordingly rather than assuming fixes will land.
- How do I implement dependent select fields in Laravel without this package?
- Build it from scratch using the bundle only as a specification. Create one route such as GET /api/options/{field} backed by a whitelist map of field to query, returning a list of value and label pairs. Add one Blade partial or small JS module that repopulates the child select and clears stale child selections, plus server-side validation of the submitted parent-child combination. The whole pattern typically takes one to three engineer-days.
- Does DependentSelectBundle use Doctrine or Eloquent for dependent options?
- Cascading-select logic of this vintage is usually configuration-driven against Doctrine entity repositories, which is Eloquent-incompatible regardless of the framework question. Whether the data source is abstracted behind an interface or hard-wired to Doctrine is one of the key questions to answer before reusing any of the code. If it is hard-wired, you would be rewriting the data layer anyway.
- Is the AJAX endpoint in this bundle safe to expose in production?
- A generic resolve-children-for-field-X controller is exactly where enumeration and unconstrained-query bugs tend to live. Before reusing the pattern, verify that the endpoint is authenticated and that it whitelists which parent fields may be queried. Even as reference code it is worth reading closely, but it is not worth inheriting unexamined. Enforce the same whitelist and authorization rules in any Laravel route you build.
- Can I copy the DependentSelectBundle source into my Laravel project as a template?
- Only after confirming the license, which is currently unverified and is a gating item rather than a footnote for this kind of reuse. If the realistic path is code reuse as a template, you need a permissive license that clearly allows derivative works. The lower-risk route is to read it for thirty minutes, extract the pattern, and write your own implementation.
- What JavaScript dependencies does the dependent select frontend need?
- The bundle advertises a lightweight frontend with minimal JavaScript setup, but the details matter for reuse. Confirm whether the JavaScript depends on a specific Symfony form theme or a particular jQuery version before assuming it translates cleanly. In Laravel you would typically replace it with a small Alpine.js component or vanilla fetch call that swaps the select options.