Statamic Alpine Csp Forms Laravel Package

Technical Evaluation

What this is. v0.1.0 is the first public pre-release of statamic-alpine-csp-forms, a Statamic add-on that packages two things previously inlined in the UAMS site: (1) a CSP-safe Alpine.js form driver and (2) a browser-side field-conditions evaluator. It is not a general-purpose Laravel package — it is a Statamic add-on, which means its integration surface is a Laravel application running Statamic, not any Laravel application.

Architecture fit.

• Fits only where Statamic Forms + Alpine.js are already in use, and only where a Content-Security-Policy is strict enough to block Alpine's default build (which relies on runtime function construction and therefore requires unsafe-eval). If your CSP is permissive today, this add-on buys you nothing and adds a dependency.
• The value proposition is genuinely narrow and genuine: strict CSP without unsafe-eval is a common audit finding for public-sector and university sites, and the standard workaround — the Alpine CSP build — historically breaks Statamic's conditional field logic. This package appears to close that specific gap.
• The bundled field-conditions evaluator means form conditional logic now exists in two places: Statamic's server-side PHP evaluator and this add-on's browser-side JS. That duplication is the central architectural risk, not the CSP work.

Integration feasibility.

• Low mechanical effort: Composer install, publish/register the add-on, swap the form driver, ensure the Alpine CSP build is loaded instead of the default build. The hard part is verifying behavioural parity, not wiring.
• The "moved out of the UAMS site" provenance is a positive signal for real-world use but also means the code was extracted for one site's requirements. Extracted code tends to carry assumptions (specific fieldtypes, specific condition operators, specific markup) that are undocumented at 0.1.0.

Technical risk.

• Pre-1.0 with declared breaking changes on minor releases. The release notes state this explicitly and commit to leading each breaking change with the required action. That is good practice, but it means ^0.1 is not a safe constraint; exact-pin and read every changelog.
• Unknown compatibility matrix. No stated Statamic version range, Alpine version, PHP version, or Laravel version. This is the single biggest unknown for a TPM deciding whether to schedule a spike.
• Behavioural divergence between client-side and server-side condition evaluation — silent, data-affecting, and hard to detect without deliberate test coverage. Symptoms would be fields shown/hidden incorrectly at submission time, and validation errors that don't match what the user saw.
• Graceful degradation. A CSP-safe driver still depends on JS executing. If the driver fails to load, is blocked by a policy, or throws, do forms fall back to showing all fields (safe-ish) or none (data loss)? Unverified.
• Bus factor. Single-institution origin (UAMS), no indication of external contributors. MIT licensing mitigates abandonment risk by permitting a fork, but the fork cost is non-trivial for a browser-side evaluator.

Key questions to put to the maintainer before committing.

1. Exact support matrix: Statamic, Laravel, PHP, Alpine, and the Alpine CSP build version.
2. What is the required CSP directive set, and is unsafe-eval fully eliminated or merely reduced?
3. Which Statamic condition operators and fieldtypes are implemented client-side, and what happens on an unimplemented operator — fail open, fail closed, or console error?
4. Test coverage and mutation-testing results (a mutation-instrument CI job exists; what is the score, and against what threshold?).
5. Is there a divergence test that asserts client and server evaluators agree across a fixture set of conditions?
6. What is the security disclosure process, and is there a supported-versions policy?
7. What is the intended 1.0.0 scope and rough timeline?

Integration Approach

Stack fit.

• Requires: Laravel + Statamic (version TBD), Alpine.js running as the CSP build, Statamic Forms in active use, and a CSP that is strict or intended to become strict.
• Does not fit: non-Statamic Laravel apps, sites using Livewire/Inertia for forms, sites relying on Alpine's standard build and unsafe-eval, or sites with no CSP ambition.

Migration path.

1. Inventory current form behaviour. Enumerate every Statamic form, every conditional field, and every condition operator actually in use. This list becomes your parity checklist and is the real cost of adoption.
2. Confirm the CSP build is viable for your Alpine usage. If any custom Alpine components use new Function, eval-based expressions, or plugins incompatible with the CSP build, they must be rewritten or dropped before this add-on helps you.
3. Roll out the CSP header in report-only mode first (Content-Security-Policy-Report-Only) to enumerate violations without breaking the site, and capture securitypolicyviolation events in the browser.
4. Adopt the add-on behind a feature flag on a single low-traffic form, with server-side validation as the authoritative gate throughout.
5. Run parity in parallel, not sequentially: submit the same fixtures through the old and new paths and diff the field sets and validation outcomes.

Compatibility and sequencing.

• Pin to an exact patch version (0.1.0, then deliberate bumps), not a caret range. Re-read release notes before every bump; assume any 0.x minor may require action.
• Upgrade order: Alpine CSP build pinned and verified → add-on installed → single form → all forms → enforce CSP (drop report-only).
• Keep server-side validation strictly authoritative. Treat the browser evaluator as a UX layer; never let it be the only enforcement of a condition that has data-integrity consequences.
• Defer broad rollout if the support matrix comes back narrower than your current Statamic version — the cost of being the first external adopter on an unsupported version outweighs the CSP benefit.

Alternative to weigh. If your CSP only needs unsafe-eval for Alpine and you have few conditional fields, rewriting those specific forms without conditional logic (or with server-driven progressive disclosure) may be cheaper than adopting a 0.x dependency plus a parity test suite.

Operational Impact

Maintenance.

• Low code footprint, but you inherit the responsibility of tracking a pre-1.0 changelog closely. Budget a small standing allocation per upgrade cycle for reading notes, testing parity, and bumping the pin.
• The add-on duplicates logic that Statamic itself owns at the server. When Statamic changes its field-condition semantics in a future major, this add-on must follow — and at 0.x there is no committed timeline for that. This is a persistent, low-grade maintenance tax rather than a one-off integration cost.
• MIT license means you can vendor or fork if it is abandoned; budget for that contingency only if your CSP deadline is hard and the dependency is load-bearing.

Support.

• No stated support policy, no supported-versions table, no security disclosure process in the release notes. For a public-sector/university-origin package this is likely to arrive with 1.0.0, but until then treat support as best-effort, GitHub-issue-based.
• Internal ramp-up is the real support cost: whoever owns forms needs to understand both the Statamic server-side condition model and this browser-side evaluator to debug mismatches. Small, Alpine-literate surface; not zero.

Scaling.

• Client-side evaluation of field conditions is negligible compute; scaling is a non-issue at any realistic form volume.
• The evaluator is shipped to the browser, so payload size and parse cost scale with the number of forms/fields per page. Worth measuring once you have more than a handful of conditional forms on one page.
• The add-on does not address submission throughput, storage, or spam handling — those remain Statamic/Laravel concerns and are unaffected.

Failure modes to plan for.

Ramp-up.

• Modest and bounded: an afternoon to install and validate one form; one to two days for a full parity pass across an existing form inventory, dominated by enumerating and testing conditions rather than by the integration itself.
• Requires someone comfortable with Alpine.js and with reading CSP violation reports. If neither exists on the team, add that to the cost.

Recommendation. Worth a time-boxed spike rather than a commitment. The problem it solves is real and the license and provenance are sound, but at 0.1.0 the compatibility matrix, test coverage, and client/server parity guarantees are all unverified, and the release policy explicitly permits breaking changes on minor versions. Gate adoption on satisfactory answers to the compatibility and parity questions above; absent those, this is a dependency you would be debugging for the maintainer.