Laravel Selectable Laravel Package

Product Decisions This Supports

• Build vs. buy on form plumbing. This package does one narrow job: turn an Eloquent/Collection into <option> markup or a structured array. The real decision isn't "do we need this capability" (every Laravel CRUD surface does) — it's whether a ~single-maintainer, 5-star, zero-dependent utility is cheaper to adopt than the 40–80 lines of internal Blade component most teams already write. Treat it as a utility-tier buy, not a platform-tier one.
• Feature scoping for admin/internal tooling. The fluent API (withLabel, withValue, withSelected, withDisabled, withDataAttribute, withClass, withId, groupBy) maps directly onto recurring backlog tickets: "show full name instead of email in the dropdown," "pre-select the current assignee," "grey out inactive accounts," "group users by department." Those are usually 1-point stories; this collapses them to one-line diffs.
• SPA/AJAX form architecture. toSelectItems() returns a stable, documented shape (label, value, selected, disabled, dataAttributes, classes). That makes it a viable serialization contract between Laravel and a Vue/Alpine/Livewire front end — the one part of this package with more than cosmetic value, because it standardizes a payload format your front end can rely on.
• Consistency decision across a codebase. The underrated PM argument isn't speed, it's uniformity: one option-rendering path means selected/disabled/data-attribute logic is implemented once instead of re-improvised per Blade file (where it typically drifts and produces bugs like "the edit form doesn't pre-select").
• Roadmap signal, not a roadmap item. Recent release cadence (v1.0.0 → v1.0.5, with array-collection support, IDE helpers, and rendering performance work) shows an attentive author. That supports piloting it in a low-blast-radius area; it does not support putting it on a critical path.

When to Consider This Package

Adopt (or pilot) when:

• You have a Blade-first, server-rendered Laravel app with many forms and no existing form-abstraction layer.
• You're writing the same <option value="{{ $x->id }}" {{ $selected ? 'selected' : '' }}> block more than a handful of times.
• You need conditional option state (disabled by status, data attributes for JS behavior, dynamic labels from concatenated fields) and want it expressed as closures rather than @foreach + @if soup.
• You want optgroup support for free via groupBy() — the highest-effort thing to hand-roll correctly.
• You need to feed selects from in-memory collections you've already filtered/sorted (permissions-scoped lists, computed sets) rather than from a fresh query.
• You're comfortable pinning a version and treating it as vendorable (MIT, small surface area).

Look elsewhere when:

• You already use a form/UI layer. Filament, Livewire form objects, Blade UI kits, Inertia + a JS select library, or Laravel Collective all own this problem. Adding this creates two sources of truth for option rendering.
• You need remote/large-dataset selects. This package formats collections you already loaded. It offers no search endpoint, pagination, lazy loading, or debounced querying. Thousands of options will render thousands of <option> tags — a performance and UX dead end. Use a proper async select backed by an API.
• Adoption risk is unacceptable for the surface. 5 stars, 0 dependents, single author. That's a supply-chain and bus-factor concern. If the select lives in a checkout flow or a regulated workflow, fork it internally or accept only as a dev-time convenience wrapped behind your own helper.
• You can't verify output escaping. The README's examples use unescaped Blade output ({!! ... !!}). Before shipping anywhere user-controlled strings (names, titles) reach a label, confirm the package escapes label/value content. If it doesn't, that's an XSS exposure introduced by convenience — a hard blocker, not a nitpick.
• You're on an unsupported PHP/Laravel pair. Check the require constraints against your matrix before anyone writes code; the PHP badge is the fastest gate.

How to Pitch It (Stakeholders)

To executives (30 seconds): A small, free MIT utility that removes repetitive boilerplate from our Laravel admin forms and standardizes how dropdowns get rendered. Expected benefit is modest but real: fewer small form bugs, faster delivery of routine CRUD tickets, and a consistent payload for our front-end selects. Cost is one dependency with no infrastructure impact. Risk is low if we isolate it behind our own helper and pin the version — it's maintained by a single author with minimal adoption, so we treat it as something we could absorb in an afternoon rather than a platform commitment. Recommendation: pilot in internal admin screens, not in customer-facing or payment flows.

To engineering (the actual pitch): One composer require, no config, no service provider. $collection->toSelectOptions() for the simple case; chain toSelectable()->withLabel(fn($u) => "{$u->first_name} {$u->last_name}")->withSelected($ids)->withDisabled(...)->withDataAttribute(...)->toSelectOptions() for the messy case; ->toSelectItems() when you need a JSON array for Vue/Alpine instead of HTML. groupBy() gives you optgroup without hand-rolling it, and it handles both Eloquent models and plain arrays. Two asks before merge: (1) wrap it in a single internal Blade component/helper so swapping it out is a one-file change, and (2) write one test asserting labels and values are HTML-escaped — if they aren't, we escape at the wrapper or we walk away. Pin the version, no floating constraint, and keep it out of any code path where an unescaped label would be an XSS vector.

Bottom line for the decision log: Low-cost, low-risk convenience dependency with a genuinely useful toSelectItems() serialization contract and optgroup support. Adopt narrowly, wrap defensively, escape-verify first, and don't mistake it for a select/search strategy.