Livewire Forms Laravel Package

Technical Evaluation

Architecture fit

• The package is not a general-purpose form library; it is a Statamic addon whose value is entirely contingent on already running Statamic 5.0+ on Laravel with Livewire. If the platform is vanilla Laravel, Laravel Nova, or a headless CMS, there is no integration path — this is a hard gate, not a preference.
• Where it does fit, the architectural argument is strong: Statamic form blueprints become the single source of truth for field definitions, validation rules, display conditions, and multi-site translations. That eliminates the classic duplicate-validation problem (client-side rules drifting from server-side rules), which is a recurring source of defects and security gaps in form-heavy applications.
• It replaces two moving parts (AJAX submission handlers + a JS validation library like jQuery Validate or vee-validate) with one Livewire component, reducing the number of bespoke integration seams the team owns.
• The extension model is well-designed for a TPM's purposes: field models map Statamic fieldtypes to Livewire field classes, and mountedFields / formSubmitted hooks provide defined override points. Customization happens through documented contracts rather than forking.

Integration feasibility

• Onboarding is low-friction: composer require, an optional config publish, and an interactive livewire-forms:setup wizard that scaffolds the first view, theme, and component. Four generator commands cover the common customization paths.
• Two non-trivial prerequisites must be confirmed before estimation: (1) the frontend must be on Tailwind CSS + @tailwindcss/forms for the shipped views to render correctly (or the team must budget to rewrite them), and (2) projects using Vite/manual Livewire+Alpine bundling must hand-import the package's JS/CSS (form.js minimum, plus filepond.js/grecaptcha.js conditionally) and remove the @formAssets directive. That is easy to get wrong and will present as a silent styling/behavior regression.
• Rendering is a one-liner in either Antlers ({{ livewire:form handle="contact" }}) or Blade (<livewire:form handle="contact">), and supports dynamic form selection via Statamic's Form fieldtype — useful for CMS-driven landing pages.
• Autoloading conventions (component class name ends in Form, themes/views/field views resolve by handle with fallback to defaults) mean the default path requires no configuration, which is good for a first proof of value.

Technical risk

• License is the top risk. GitHub reports NOASSERTION, meaning the license could not be identified from the repository. This is a legal-review blocker in most organizations and must be resolved in writing before any production dependency.
• Bus factor and ecosystem depth are thin. 29 stars, 0 dependents, effectively a single maintainer. There is no evidence of a paid support tier, LTS branch, or security disclosure policy.
• Documented forward-compatibility hazard. The README explicitly states future releases will likely introduce breaking changes to published views, requiring manual updates. Published views/themes are effectively forked into the consumer's codebase, so every upstream release becomes a merge task.
• Maturity signals are ambiguous. "Maturity: readme, releases" with no test suite, no changelog depth, and no docs site. The metadata also shows a last-release date in the future (2026-11-02), which is likely a metadata artifact but should be verified against Packagist before treating release cadence as evidence of health.
• Version coupling. The package sits on three fast-moving dependencies simultaneously (Statamic 5, Livewire 3, Alpine). Any major bump in Livewire's component lifecycle or Alpine's plugin model can cascade.
• Spam protection is reCAPTCHA v2, not v3 or Enterprise. v2 introduces a user-friction and accessibility trade-off that may conflict with conversion OKRs.

Key questions

• What is the actual license text, and has legal signed off on redistribution and modification of the published views?
• What Livewire and Statamic version ranges are pinned in composer.json, and what is the maintainer's stated support window?
• Is there a test suite or CI, and what is the maintainer's responsiveness on issues/PRs over the last 6–12 months?
• Which Statamic fieldtypes in our current forms are unsupported and would require custom field models?
• Are the published views expected to be treated as owned code (forked) or as upstream-tracked? This determines long-term maintenance cost.
• Does the reCAPTCHA v2 requirement pass our accessibility and privacy review (Google data processing)?

Integration Approach

Stack fit

• Target stack: Laravel + Statamic 5.0+ + Livewire 3 + Alpine + Tailwind (with @tailwindcss/forms). Any deviation from that stack increases cost materially — particularly a non-Tailwind design system, which turns the "styled, pre-configured views" selling point into a liability.
• Fits marketing/CMS-driven sites (contact, quote request, newsletter, application forms) far better than authenticated product UI, where Livewire round-trips are less obviously a win.

Migration path

• Migrate form-by-form, not framework-first. The package is additive: existing Antlers/AJAX forms continue to work while a single form is ported.
• Recommended pilot: one low-traffic, low-risk, validation-heavy form (e.g., contact or support request) where the "one source of truth for validation" benefit is immediately observable.
• Do not port forms whose blueprints contain unsupported fieldtypes or heavy conditional logic until field models have been validated in the pilot.
• Keep the existing submission pipeline (Statamic submissions, notifications, webhooks) intact — the package sits in front of it and fires the standard FormSubmitted Statamic event, so downstream listeners are unaffected. This is the key de-risking property of the migration.

Compatibility

• Confirm Livewire and Statamic constraints from composer.json against the current app before committing.
• Verify asset pipeline: if using Vite with manual Livewire bundling, the individual-import instructions must be followed exactly and @formAssets removed, or styles/scripts will double-load or fail.
• Verify livewire:styles / livewire:scriptConfig (or Blade equivalents) are present in the layout — a common omission.
• Confirm multi-site translation coverage if the site is localized, since that is a stated feature with real configuration surface.

Sequencing

1. Legal/license review and composer.json constraint inspection (blocking).
2. Engineering spike (1–2 days): install in a branch, run livewire-forms:setup, render one form, validate reCAPTCHA + honeypot, confirm asset pipeline under the real build.
3. Publish and commit baseline views/themes so upstream drift is diffable.
4. Add one custom field model or mountedFields hook to prove the extension path with a real dynamic field (e.g., select populated from a collection).
5. Production rollout by form, with a documented rollback (the original Antlers form template remains in version control).

Operational Impact

Maintenance

• The dominant ongoing cost is view/theme drift. Once published, views are consumer-owned code and upstream breaking changes must be manually reconciled. Budget a recurring review task per upstream release rather than assuming drop-in upgrades.
• Dependency treadmill: Statamic major, Livewire major, and Alpine major each require re-validation. Pin versions and upgrade deliberately.
• Small surface area otherwise — configuration is centralized in one config file, and field model bindings are overridable globally or per-field.

Support

• Support is effectively GitHub issues from a single maintainer with 29 stars. There is no commercial SLA. Treat this as community-supported open source, and plan a fork-and-own contingency: the codebase is small enough that an internal engineer can absorb it if upstream goes dormant.
• Given NOASSERTION, there is also no clarity on whether a fork is legally permissible — reinforcing that license review precedes adoption.

Scaling

• The real scaling consideration is runtime load, not throughput: real-time per-field validation means server round-trips during form completion. Under marketing campaign traffic spikes, form pages cannot be edge-cached the way static pages can (session, CSRF, Livewire state). Size the app servers for form-page concurrency and confirm Livewire debounce settings are appropriate.
• Submission processing itself is unchanged (delegated to Statamic), so scaling characteristics of the existing submission/notification pipeline carry over — no new queue or storage requirements introduced.
• Bundled JS includes Filepond and reCAPTCHA; if those integrations aren't used, prefer individual imports to avoid shipping dead weight.

Failure modes

• Asset wiring failures: missing manual imports, stale @formAssets, or absent livewire:scriptConfig → forms render but validation/submission silently misbehave. Highest-probability operational issue.
• Blueprint drift: a content editor adds or renames a field type in the Statamic blueprint that has no field model binding → field renders empty or errors. Needs a documented "supported fieldtypes" checklist in the editorial handbook.
• reCAPTCHA misconfiguration or outage: missing/invalid keys or Google-side degradation blocks legitimate submissions; v2 also degrades accessibility. Honeypot provides partial fallback only.
• Upstream breaking change applied without reconciling published views → layout or validation regressions in production.
• Silent submission failures: if the formSubmitted hook throws (e.g., a null-safe chain on an augmented entry value), the user sees a success state while the submission is lost. Wrap custom hook logic defensively and monitor FormSubmitted events server-side as a submission-count health metric.
• Data quality anomaly in package metadata (future-dated release) — verify registry data rather than trusting the score card.

Ramp-up

• Low-to-moderate. A developer already fluent in Livewire and Statamic blueprints is productive in under a day given the setup wizard and generator commands.
• Teams without Livewire/Alpine experience need roughly 2–3 days to become confident with component lifecycle, wire: directives, and Alpine-powered display conditions — this is the hidden cost.
• Editorial/content team ramp-up is the underrated item: because blueprints drive the forms, content editors gain direct influence over form structure. Publish a short guide covering supported fieldtypes, display conditions, and translation fields, and add a review step for blueprint changes to form-bearing forms.
• Overall recommendation posture: viable and architecturally sensible, gated on license clearance, a one-form pilot, and explicit acceptance of the view-fork maintenance model. Not appropriate as a critical-path dependency without a named internal owner.