Statamic Custom Select Laravel Package

Technical Evaluation

Architecture fit. The package is a Statamic addon — a Composer-installable Laravel package that registers a service provider, a PHP fieldtype class (most plausibly extending Statamic\Fieldtypes\Select), and a Vue component for the Control Panel. This is the canonical extension point for custom fieldtypes and sits cleanly inside the existing Laravel/Statamic architecture: no new runtime, no separate service, no database schema. Field values persist as ordinary field data in the content tree, so the addon is additive rather than structural.

Integration feasibility. Mechanically trivial: composer require, add the fieldtype handle to a blueprint YAML, ship the JS assets via the addon's publish step. A developer familiar with Statamic can wire a proof of concept in under a day. The binding constraints are not technical effort but discovery and verification — the package name (linksderisar) does not match the repository owner (angelov-ldi), which raises ownership/provenance questions and, more practically, means we must confirm exactly which Packagist package (if any) is the canonical artifact, and whether the repo we reviewed is the same code that Composer would pull.

Technical risk. This is the dominant factor. Zero stars, zero dependents, and a zero composite score describe a package with no adoption signal, no community validation, and effectively no maintainer accountability. Specific risks to price in:

• Statamic version compatibility. Statamic 4/5 moved the CP to Vue 3. A custom select component built on older Vue 2 conventions will not load in a modern CP. Verify the statamic constraint in composer.json and the Vue major in the addon's package.json before anything else.
• Feature overlap. Core select already supports searchable, multiple, clearable, and option-group behavior, and options can be sourced from dictionaries, config, or a closure. A meaningful share of this addon's value may be reproducible natively, which changes the build-vs-adopt calculus entirely.
• Security surface. A custom select typically renders option labels/values into the CP; if options are supplied dynamically, confirm escaping and whether any user-influenced data reaches the DOM.
• Bus factor. Single maintainer, no visible release cadence, likely no test suite or CI.

Key questions for the maintainer/owner. What Statamic and PHP versions are supported and tested? Is the package published on Packagist under a name we can pin? Is there a license file? Does it differ from core select in a way we cannot replicate with a dictionary or a small in-house fieldtype? What is the fork-and-own cost if upstream goes quiet?

Integration Approach

Stack fit. Fits any Laravel + Statamic project with a standard Composer workflow. No infrastructure, queue, or storage implications. The only environmental prerequisite is CP asset compatibility (Vue major, Vite build output) with the target Statamic version.

Migration path. There is nothing to migrate — the fieldtype is greenfield in our blueprints. The real migration question is the exit path: because the package is unvetted, adopt it only as a fork we control (path repository or private VCS mirror) rather than as an unmanaged upstream dependency. If the fieldtype later needs replacing, existing content values remain readable as plain field data, so content migration cost is near zero; only blueprint/CP editing breaks.

Compatibility. Pin an exact version in composer.lock, assert the statamic/frontend and PHP constraints, and validate in a staging environment that mirrors production's Statamic minor. Test both CP editing and front-end/Antlers output, plus any REST/GraphQL augmentation where the field is exposed.

Sequencing.

1. Spike: reproduce the addon's differentiating behavior with core select + a dictionary or closure. If parity is achievable, stop — no dependency needed.
2. If not, install in a throwaway branch, verify CP rendering on the production Statamic version, and review the PHP/Vue source (small enough to read in full).
3. Fork to a controlled repo, add a smoke test and a changelog, and consume via path/VCS repository.
4. Roll out to one blueprint, then expand only after a full release cycle with no incidents.

Operational Impact

Maintenance. Assume we own it. With one maintainer and no adoption, upstream fixes for a Statamic major upgrade are unlikely to arrive on our schedule — historically the breaking point for Statamic fieldtypes is a CP framework bump, which is a recurring, predictable event. Budget a fork-maintenance line item (roughly a few days per Statamic major) and assign an owner.

Support. No SLA, no triage, likely thin documentation beyond a README. Internal support burden lands on the team that owns the CMS. Mitigate by documenting the fieldtype's behavior and configuration in our own blueprint conventions docs so it isn't tribal knowledge.

Scaling. Editor-side only, so front-end scale is unaffected. The scaling risk is CP responsiveness: selects with large option sets (thousands) degrade editor performance, and if options are populated dynamically per request, CP page loads can regress noticeably. Cap option counts and prefer static/dictionary-backed options where possible.

Failure modes. (1) Statamic upgrade breaks the CP component — editors lose the field, content unaffected; (2) Composer resolution conflict against the pinned Statamic version; (3) upstream repo/package removal, breaking fresh installs unless we hold a fork; (4) unescaped option rendering producing a stored-XSS vector in the CP; (5) abandoned upstream leaving an unpatched dependency in our SBOM. Each is cheap to contain with a fork plus a lock file, and expensive to contain without one.

Ramp-up. Low for any developer with Statamic addon experience — the code surface is a fieldtype class and a Vue component. The genuine ramp-up cost is the due diligence in step 1 above, not the integration itself.

Recommendation. Do not adopt as an unmanaged dependency at its current maturity. Run the parity spike first; if the addon is genuinely differentiated, fork it, pin it, test it, and treat it as first-party code.