Statamic Choices Laravel Package

Technical Evaluation

Architecture fit. statamic-choices is a Statamic addon distributed as a Composer package, following the conventional Laravel/Statamic addon shape: a service provider, a Control Panel (CP) UI, and a packaged Vite build. The v0.1.1 change — auto-publishing the Vite build to public/vendor/statamic-choices/build after Composer install — is the standard mechanism Statamic addons use to avoid Vite manifest errors in the CP. Architecturally this is low-friction and idiomatic; it does not introduce middleware, queues, database schema, or runtime services into the host application. Fit is good for teams already standardized on Statamic 5/6.

Integration feasibility. Installation is a single composer require, with asset publishing now automated. That removes the most common first-install failure mode (Vite manifest not found) and reduces onboarding to configuration rather than plumbing. Verification is claimed against Statamic v5 and v6 sandboxes with a passing CI run for the release commit. However, the surrounding evidence base is thin: this is the only release note available and there is no prior assessment, so feasibility is asserted by the maintainer rather than independently validated against our stack.

Technical risk. The dominant risk is maturity, not architecture. A 0.1.x version signals pre-stable APIs: fieldtype configuration, blueprint schema, and view components may change without a major-version bump. Secondary risks:

• Composer script dependency — automatic publishing relies on Composer scripts executing. Deploy pipelines using composer install --no-scripts, --no-dev with stripped scripts, or immutable/read-only release artifacts will silently regress to the manifest error.
• Filesystem expectations — the publish target must be writable at install time and present in the web root; containerized or read-only filesystem deployments need an explicit publish step.
• Vite coupling — the CP asset contract is tied to Statamic's Vite integration; Statamic CP asset-handling changes in future minors are an upgrade hazard.
• Unknown surface area — the release notes do not describe the addon's functional scope (presumably a choices/options fieldtype), PHP/Laravel constraints, test coverage, or license.

Key questions for the maintainer / evaluation team.

1. What is the addon's functional scope, and which Statamic fieldtypes or blueprint features does it replace or extend?
2. What are the declared composer.json constraints — PHP, Laravel, and Statamic versions? Is Statamic 4 or earlier supported?
3. Is the asset publish idempotent and safe to run repeatedly across deploys, and does it version/hash assets for cache busting?
4. What is the test coverage beyond the two sandbox verifications, and is CI running against a matrix of Statamic 5/6 and Laravel minors?
5. Who maintains the package, what is the release cadence, and is there a documented support or security-response channel?
6. What is the license, and are there any transitive dependencies of note?
7. What is the documented upgrade path for 0.x breaking changes?

Integration Approach

Stack fit. Appropriate for Laravel applications running Statamic 5 or 6 with a standard Composer-based deploy. It should be treated as a CP-extension dependency, not an application-layer library — it should not become a load-bearing part of content modeling without a fallback plan.

Migration path. Greenfield: composer require, confirm the publish hook fires, clear Statamic and application caches, then register the fieldtype in the relevant blueprints. Brownfield: no database migrations are implied; the change surface is configuration and published static assets. If the addon is replacing a hand-rolled choices fieldtype, plan a content-model migration and a blueprint diff review rather than a drop-in swap.

Compatibility. Verified by the maintainer against Statamic v5 and v6 sandboxes. Before adoption, confirm compatibility against the exact pinned versions in our composer.lock — especially the Laravel minor and PHP runtime — since sandbox verification is not the same as a full application test.

Sequencing.

1. Pin the dependency to an exact or narrowly constrained version; do not float 0.x in production.
2. Add to a staging environment first and confirm the Vite build lands in public/vendor/statamic-choices/build after a clean composer install.
3. Update the deploy pipeline if it uses --no-scripts or read-only release directories; add an explicit vendor:publish/asset-publish step and include the build directory in the release artifact.
4. Smoke-test the CP on the target environment (not just local) to confirm the manifest resolves behind the production web server and any CDN.
5. Promote to production with a rollback path that includes removing the package and reverting blueprints.

Operational Impact

Maintenance. Low code footprint and no runtime services means low ongoing operational cost. The real maintenance cost is upgrade surveillance: a 0.x package can ship breaking changes in patch releases, so someone must watch the release feed and re-verify after each bump. Budget a periodic compatibility check against Statamic minor upgrades.

Support. Presumed single-maintainer or small-team open source with GitHub-based support and no SLA. That is acceptable for a CP convenience feature and unacceptable for anything content-critical. Record it in the dependency register with an owner and a documented fallback (remove the addon, revert to native Statamic fieldtypes).

Scaling. Negligible. Publishing static assets is a build-time concern; there is no query, queue, or request-path overhead beyond normal service-provider boot. Asset size and CDN behavior are the only scale-adjacent considerations, and both are trivial at typical CP scale.

Failure modes.

• Manifest not found — now fixed for standard composer install, but still reachable via --no-scripts, skipped publish steps, or a missing/incorrect public/vendor path.
• Silent publish failure — a non-writable filesystem may not fail the build loudly; the symptom appears later as a broken CP, so add an explicit post-deploy assertion that the build directory exists.
• Stale assets after upgrade — cached CP assets or CDN edge copies can serve an old manifest after a version bump; require a cache-clear step in the runbook.
• Blueprint breakage on 0.x upgrade — configuration schema changes may render existing blueprints invalid; stage upgrades before production.

Ramp-up. Low for developers already fluent in Statamic addon conventions — roughly hours to first use. The TPM-facing ramp-up is process, not code: establishing the version pin, the deploy-script adjustment, and the upgrade-watch owner. Recommend a time-boxed pilot (one non-critical blueprint, one sprint) before broader adoption, and a go/no-go review once the addon reaches 1.0 or demonstrates a stable API across several releases.