Select All Choice Bundle Laravel Package

Technical Evaluation

Framing correction: despite the “Laravel/PHP package” label, this is a Symfony 7/8 bundle (nowo-tech/select-all-choice-bundle). It registers a form type extension on ChoiceType (multiple=true) and ships a Twig form theme plus a Stimulus controller. There is no Laravel service provider, Blade view, or Form macro. Any “leverage” for a Laravel team is therefore pattern reuse, not dependency adoption.

Architecture fit

• Symfony apps: good fit. Small, convention-following bundle; backend only marks the field and emits config via data-*; all toggle behavior is client-side in Stimulus. Clean separation, low coupling.
• Laravel apps: no direct fit. The transferable assets are (a) the data-attribute contract between server-rendered markup and the controller, and (b) the Stimulus controller itself — Stimulus is framework-agnostic and can run in Laravel alongside Blade, or be re-expressed in Alpine.js.
• Livewire/Inertia: only workable if the controller re-initializes after DOM morphs; upstream provides no evidence of this.

Integration feasibility

• Symfony: composer require, enable bundle, set the option on the field, ensure the form theme and Stimulus controller are loaded. Sub-day effort.
• Laravel: requires a port — a Blade component (or Form::macro) emitting the same data-* hooks, plus an Alpine/Stimulus controller. Realistically 1–3 dev days including tests.

Technical risk

• Ecosystem signal is near zero: 0 stars, 0 dependents, no community validation, apparent single maintainer. Treat as unvetted code.
• Metadata anomaly: last release dated 2026-10-25, a future date. Verify tags, Composer metadata, and CI provenance before trusting the artifact; this may indicate a misconfigured pipeline or fabricated metadata.
• Blast radius is small (frontend-only, no persistence, no server-side behavior change), which materially lowers risk.
• Intrinsic complexity is understated: “select all” is deceptively stateful — indeterminate/partial state, disabled options, dynamically added options, server-side re-render, and validation interplay.

Key questions

1. Does it handle the indeterminate/mixed visual state, and is it exposed via aria-checked="mixed"?
2. How are disabled options treated — skipped, or included and coerced?
3. Does the “select all” control itself submit a value, and does that pollute the bound array?
4. Behavior after partial DOM replacement (Livewire, Turbo, Inertia) — is there a re-init hook?
5. Any no-JS fallback, or does the UI degrade to a misleading inert control?
6. Interaction with JS-enhanced selects (Tom Select, Select2, Choices.js) — tested or conflicting?
7. Server-side validation parity: does the toggle ever produce a payload the backend rejects?

Integration Approach

Stack fit

Migration path (Laravel)

1. Extract the Stimulus controller and the data-* contract as a reference specification, not a copy-paste dependency.
2. Author a <x-select-all> Blade component that renders the master checkbox and annotates the target select/checkbox group with matching data attributes.
3. Either register the original controller via @hotwired/stimulus (cheapest, keeps upstream parity) or reimplement in Alpine (~40 lines, avoids a new runtime).
4. Mirror the server contract: the “select all” control must not be part of the validated payload; the array of selected IDs remains the only submitted value.
5. Cover it with a Dusk/Pest browser test asserting: all-selected → all checked; one unchecked → indeterminate; disabled option untouched.

Compatibility

• Upstream: PHP ≥8.1, Symfony 7/8, Stimulus 3.x. Note the repo rules target PHP 8.1 / Symfony 6–7–8, so 6.x support is ambiguous — confirm before relying on it.
• Target Laravel: Laravel 10/11+ with Alpine 3 or Stimulus 3. No PHP version conflict in the port path.

Sequencing

1. Provenance/release-metadata audit (half day) — gate for everything else.
2. Spike in a throwaway Symfony sandbox only if a Symfony service exists in the estate; otherwise skip.
3. Extract the contract + controller; document the attribute schema.
4. Build the Blade component and JS; wire into one real form.
5. Browser test matrix (expanded, collapsed, partial, disabled, dynamic options).
6. Publish an internal snippet/package so the next team doesn’t repeat the work.

Operational Impact

Maintenance

• As a dependency: tiny surface, but it inherits your dependency-update treadmill for zero strategic benefit in a Laravel estate.
• As a port: you own ~100 lines of markup + JS. Trivial, but it is now yours; assign an owner.
• Upstream activity is unproven (0 stars, 0 dependents) — assume no upstream maintenance and plan accordingly.

Support

• No community, no dependents, single maintainer → no external support channel. Internal ownership is mandatory, not optional.
• Licensing is MIT (clean); no legal review burden beyond the usual notice file.

Scaling

• Client-side only; no server or database cost.
• Performance concern is O(n) per toggle over the option set: fine to ~1–2k options, degrading beyond that. For large lists, prefer server-side “select all matching filter” semantics rather than a DOM-wide loop.
• No impact on request size unless the master control leaks a value into the submitted array — verify.

Failure modes

• Desync: master checkbox and individual inputs disagree after partial re-render (Livewire/Turbo) — listeners bound once, elements replaced.
• Indeterminate not represented: users can’t tell “some selected” from “none selected,” producing silent mis-selection.
• Disabled options coerced: hidden inputs or .prop('checked') sweeps that include disabled/optgroup children.
• No-JS degradation: backend only marks the field, so with JS blocked the control may render inert or absent — an accessibility and trust issue.
• Payload pollution: master checkbox name colliding with the bound collection, causing validation surprises.
• Silent breakage on Stimulus upgrade if the version is unpinned.

Ramp-up

• Symfony team: a few hours; the option and theme wiring are self-evident.
• Laravel team: half a day to read the contract, 1–3 days to port and test. Frontend-capable engineer required for the indeterminate/ARIA edge cases.

Recommendation: Do not add this as a Composer dependency in a Laravel codebase — it cannot be consumed there. Treat it as a reference implementation for a “select all” Blade/Alpine component, gated on a provenance check of the anomalous 2026 release date. If a Symfony 7/8 service exists in the estate, adopt directly after that check; the risk is low and the integration is under a day.