Wire Forms Laravel Package

Technical Evaluation

Architecture fit. wire-forms targets a well-defined seam in a Laravel/Livewire codebase: the form layer that every product rebuilds — field definitions, state binding, validation wiring, error rendering, layout grid, repeaters, reset semantics. Architecturally it is a thin presentation abstraction, not a framework, not a panel. That is the right shape for the only adoption posture this package supports: internal tools, back-office CRUD, settings screens, MVPs. It is the wrong shape for anything where form behaviour is a product differentiator, where accessibility or i18n is contractual, or where Filament/Nova already owns the admin surface. A TPM's first job is scoping adoption to the former and writing the latter down as an explicit non-goal so it is not relitigated per-sprint.

The strategic question to bank or discard early is the "standalone" claim. Two readings have very different architectural consequences:

Do not let the team build an architecture story on the first reading until someone has confirmed it in source. This is a gate, not an assumption.

Integration feasibility. Feasible, and cheap to test — the package is small enough to read in an afternoon and MIT-licensed, so the code can be forked, vendored, and patched. Integration is bounded: a form class per resource, instantiated in a Livewire component, bound in Blade, validated on submit. The real feasibility risk is not "can we wire it up," it is "does it behave correctly at the edges we care about." Three feasibility questions dominate, in order:

1. Does the validation path delegate to Illuminate\Validation\Factory? Look for Validator::make, Rule contract handling, and whether FormRequest and custom Rule objects survive intact. Any evidence of hand-rolled rule evaluation ends the evaluation. Every divergence becomes an exploitable defect, and at zero dependents there is no upstream security process to report into. This is the single go/no-go gate and it must be owned by a named engineer, not "the team."
2. Livewire major-version coupling. Livewire 3 → 4 changed class-level behaviour that routinely breaks form packages. With zero dependents, we will be the ones discovering breakage — in production. Pin livewire/livewire alongside the package and gate both behind a single dependency PR.
3. Silent attribute dropping. If an unknown prop on a field component vanishes quietly rather than erroring or forwarding, aria-*, wire:model modifiers, and data-* test hooks disappear without anyone noticing. This is the accessibility failure mode and it needs an explicit test on day one.

Technical risk. The dominant risk is not code quality — it is bus factor of one combined with zero public evidence of use. Zero stars, zero dependents, no issue history, no downstream corpus, no composite score. Assume the maintainer goes quiet the week after adoption. Everything else is secondary:

• Validator divergence — high impact, mitigated only by the gate above.
• Livewire upgrade breakage — high likelihood over any horizon beyond two quarters, mitigated by pinning and an absorb-through-fork policy.
• Pre-1.0 semver volatility — ^0.x permits breaking changes in a patch. Pin the exact version (0.1.4). Non-negotiable.
• Namespace/asset collisions with blade-ui-kit and existing Livewire component registrations — low impact, cheap to check early.
• Error bag mismatch — the package may write to a named bag while layout renders $errors elsewhere; inline messages silently fail to appear. Cheap to catch in a spike, expensive to catch in QA.
• Reset/hydration state leakage — a create form pre-filled with the last edited record is an embarrassing bug class that form packages commonly ship.

Key questions the evaluation must answer before a go decision.

• Does validation delegate to Illuminate\Validation\Factory and pass Rule/FormRequest objects through unchanged? (blocking)
• What exactly does "standalone" mean — cross-context schema reuse, or merely suite-independent? (blocking for the architecture story)
• Do composer.json constraints on php, laravel/framework, and livewire/livewire cover our current stack and the next Laravel LTS? (blocking)
• Which error bag does it write to, and does our layout read that bag?
• Do repeaters and conditional fields work with nested keys (items.*.name) the way Laravel expects?
• Do unknown props error or forward, rather than silently drop?
• Is the reset() / re-mount path clean between records?
• Is there any clean way to keep persistence and side effects out of the form class?

Integration Approach

Stack fit. Requires Laravel 10/11+ with Blade and Livewire 3. Fit is good where form work is repetitive rather than novel and the field vocabulary is conventional — text, select, standard validation rules, a layout grid. Poor fit for edge-case-heavy forms (complex conditional logic, heavy file handling), API-first Inertia/Vue front ends where server-rendered field components add little, and any environment already running Filament, where you would be maintaining two layout systems and two validation paths for one job.

Migration path. There is no migration path, and that is deliberate. New forms only. Do not migrate existing screens. Adoption risk must be bounded to code the team was going to write anyway; retrofitting an unproven abstraction onto working screens converts an experiment into a migration project with no offsetting benefit. The corollary is a scope commitment the TPM should state plainly in the kickoff: existing form code is frozen with respect to this package, and any request to migrate it routes through a separate decision with its own risk case.

Compatibility. Three compatibility surfaces need explicit controls:

• Version pinning. Exact version (0.1.4), never a caret on 0.x. Livewire pinned in lockstep. Both upgrades routed through one dependency PR with the fixture form as smoke test.
• Dependency constraints. composer why-not nyoncode/wire-forms 0.1.4 against the lockfile before any code is written; confirm coverage of current and next Laravel LTS.
• Collision surface. Namespace and asset collisions with blade-ui-kit, existing Livewire component registrations, and any shipped views/CSS/JS. Version or namespace package assets so they don't fight the design system on the next upgrade.

Sequencing. A timeboxed, gated sequence — each step produces an artefact and has a defined stop condition:

1. Fork first, install second. Fork to the org, point Composer at the VCS, pin 0.1.4. The fork is not paranoia; it is the only mechanism by which we can ship a patch. Precondition for everything downstream.
2. Read the source before the README. Specifically the validation path and composer.json constraints. Stop condition: hand-rolled rule evaluation → evaluation ends here.
3. Build the thin internal adapter seam. One directory of our own base classes or wrapper Blade components delegating to wire-forms. Roughly a day. Payoff: swapping to filament/forms, native Livewire form objects, or raw Blade later becomes a mechanical edit rather than a rewrite. Without the seam, "cheap to try" stops being true at forty forms.
4. Spike on one internal settings screen — a handful of fields, one required|email, one conditional field, one submit. Not the checkout page, not anything customer-facing. Confirm: errors land in the bag Blade already reads; failed submit repopulates without manual fill(); unknown props fail loudly.
5. Spike the hard cases on the second form — repeaters and conditional fields, explicitly, in the spike, not in month three. Nested validation keys are where form abstractions most often diverge from Laravel's expectations.
6. Produce the fixture form and the findings note. One fixture exercising every field type we depend on is the upgrade smoke test and the single most valuable artefact of the whole exercise. The deliverable is a one-page findings note, not merged production code.
7. Widen adoption only after one minor Livewire upgrade is absorbed through the fork. That upgrade is the real proof of the ownership model, not the spike.

Validation layering is an architectural constraint, not a recommendation. Write it into the ADR: the package's validation is a UX affordance — fast feedback, inline messages, no full-page round trip — and is never the trust boundary. A FormRequest or explicit authoritative $this->validate() stays on the server-side write path for anything touching money, permissions, or persisted records. If form-object rules and FormRequest rules drift, we have two sources of truth and the weaker one is public-facing.

Operational Impact

Maintenance. Budget honestly: 5–10% of one engineer's time in year one for fork upkeep, dependency bumps, and internal docs. If upstream activity materialises, that drops. If it stays dormant, it rises — which is precisely what the fork and the adapter seam exist to absorb. Assign a named owner. An unowned fork is a fork that rots, and the failure will surface as a blocked Livewire upgrade six months out with nobody holding context.

Support. There is no upstream support channel worth planning against: no issue history, no downstream corpus, no community. Internal support means internal docs, internal tests, and internal ownership. Two artefacts carry most of that weight and should be treated as deliverables, not nice-to-haves:

• The fixture form — upgrade smoke test, and the fastest way for a new engineer to see every field type in use.
• The one-page findings note from the spike — the record of what was verified, what was assumed, and what was deliberately excluded.

Scaling. Two distinct scaling axes with opposite answers:

• Breadth of adoption scales cheaply only through the adapter seam. Forty forms behind our own base classes is a mechanical swap if we exit; forty forms calling the package directly is a rewrite. The seam is a one-day cost that decides whether "reversible" stays true.
• Team scaling scales poorly without documentation, because there is no external corpus to learn from. The mitigation is the standardise-once pattern: one layout grid, one field wrapper emitting label/help/error/aria-describedby consistently. Retrofitting aria-invalid across forty screens later is a genuinely miserable sprint, and it is the kind of work no roadmap ever accounts for.

Failure modes. Named, with the detection and the response:

The one failure mode that is genuinely unmitigable is silent validator divergence in production, because there is no upstream security process to disclose into. That is why the gate at step 2 is a hard stop rather than a risk to be accepted with monitoring.

Ramp-up. Low for the mechanics, higher than it looks for the judgement. A Laravel developer reads the source in an afternoon and lands the first form in a day. The non-obvious skills are the ones that decide whether adoption pays off: keeping the form class a thin schema description and keeping authorization, persistence, and side effects out of it (form objects that grow a save() method become the thing you cannot test); testing the form class rather than the markup; and resisting the urge to migrate existing screens. Plan for a half-day of internal walkthrough on the adapter seam and the fixture form, and write the validation-layering constraint into the ADR so it survives team turnover.

Go/no-go framing for stakeholders. The decision is reversible if the seam exists and the fork is owned. Downside is bounded to integration effort, not a migration project. Where it fits: internal tools, back-office CRUD, settings screens, MVPs, prototype-heavy phases. Where it doesn't: customer-facing differentiator forms, accessibility- or i18n-contractual surfaces, payment-adjacent flows, or a roadmap that depends on this layer for years rather than months.