Pest Plugin Livewire Laravel Package

Technical Evaluation

What the TPM is actually evaluating. This is not a product dependency. It is a dev-only Pest plugin — a thin DX layer of helpers (livewire(), chainable assertions, custom expectations) over Livewire's native test primitives. It ships no runtime code, no routes, no container bindings. Blast radius is confined to CI. The TPM decision is therefore dependency governance and test-strategy standardization, not architecture.

Architecture fit. Narrow and contracting. It fits a require-dev slot in a Laravel + Pest + Livewire, form-heavy suite where engineers already write Livewire::test() assertions and want less boilerplate. The decisive architectural fact: Livewire 3 ships fillForm, assertFormSet, assertHasErrors, and assertHasNoFormErrors, which covers most of this plugin's reason to exist. The capability has been upstreamed; the package is now largely redundant rather than merely risky.

Integration feasibility. Mechanically trivial — composer require --dev, plugin auto-discovery, optionally a trait in tests/Pest.php, no config, no migration. The blocker is not effort; it is version drift. Last release 2.0 (2023-04-18) added Pest V2 support and predates Livewire 3, Pest 2/3, Laravel 10/11, and PHPUnit 10/11 internals. Expect composer resolution conflicts on modern stacks or, worse, silent assertion mismatches that keep the suite green while asserting less than the team believes.

Technical risk.

• Abandonment (high, dominant): archived upstream; no fixes for Pest plugin API changes, PHPUnit internals, or Livewire 3 semantics. Any adoption transfers ownership to us.
• No community validation (high signal): 0 stars, 0 dependents, no issue triage, no production hardening. For a standing dependency this is a strong negative.
• False-green tests (highest consequence): helpers that "pass" against drifted behavior erode trust in the whole suite. This is the failure mode a TPM should weight above all others.
• Supply chain (low–moderate): dev-only so no production exposure, but archived/obscure names are common typosquatting and dependency-confusion targets. Verify Packagist vendor and lockfile hash on any install.
• API collision (low): duplicates Livewire 3's assertion vocabulary, creating two idioms for the same job in one suite.
• Governance smell (moderate): the temptation to pin pest ^1 / livewire ^2 in a service purely to keep a test helper alive — a bad trade against the upgrade roadmap.

Key questions to get answered before any decision.

1. What Pest / Livewire / Laravel / PHP constraints does our composer.json allow, and does it install cleanly across the full CI matrix?
2. Which helpers does it add that Livewire 3 native form testing does not already cover? If "none," retire without further analysis.
3. How large is the source? A few hundred lines means vendoring or reimplementing is cheaper than owning an abandoned dependency.
4. Do any tests depend on it today? Zero registry dependents suggests no — but audit the codebase, not the registry.
5. If we fork, who owns it, and is MIT attribution preserved?

Assessment. Do not adopt as a standing external dependency for a long-lived project. Treat it as a short, time-boxed spike candidate or a source-level fork. The TPM job is governance, not architecture.

Integration Approach

Stack fit. Valid only for a Laravel + Pest + Livewire form-heavy test suite already writing Livewire::test() assertions. On Livewire 3, native form helpers remove most of the motivation. The only honest justification is a legacy pin — Livewire 2.x + Pest 1.x — where the ergonomics outweigh upgrade friction, and even then with eyes open about the archived upstream.

Migration path (when already present in a legacy codebase).

1. Audit: read composer.json constraints and the plugin's src/; inventory each helper and map it to a native Livewire 3 equivalent (fillForm, assertFormSet, assertHasErrors, assertHasNoFormErrors) or to a local trait method.
2. Reimplement or fork: copy the handful of helpers into tests/Support/LivewireFormAssertions.php (or an internal dev path package) under our namespace, preserving MIT attribution.
3. Swap registration: replace the plugin trait in tests/Pest.php with the internal trait, keeping method names identical so no test bodies change.
4. Remove the dependency: drop from composer.json, refresh the lockfile, confirm no transitive pest-plugin-api / phpunit pinning remains, close the spike branch.

Compatibility. Do not co-install with Pest 2+/Livewire 3 without an isolated CI spike first. The 2.0 release targets Pest 1.x/2.x with Livewire 2.x on roughly PHP 8.0–8.1 (inferred from the April 2023 date, before Livewire 3 shipped). On Livewire 3, prefer rewriting assertions against native helpers over porting — lower risk, lower total cost.

Sequencing.

• Week 1: Spike branch — install in an isolated worktree, run against one representative Livewire form test, record failures and gaps versus native equivalents.
• Week 1–2: Decision gate — fork vs. reimplement vs. drop. Default to reimplement given the tiny API surface and archived upstream.
• Week 2: Run the matrix (PHP 8.1–8.3, Laravel 10/11, Livewire 3, Pest 2/3) for whichever path is chosen.
• Week 2–3: Remove the external dependency, land the internal trait, update tests/Pest.php, merge.

Total budget: one to two days of engineering to audit and migrate, plus the spike. This is a cleanup ticket, not a roadmap item. The TPM's deliverable is the decision record and the ownership assignment, not the code.

Operational Impact

Maintenance. Upstream maintenance is effectively zero — archived — so any adoption transfers ownership to us. The surface is small, so ongoing cost is bounded (a few hours per major Pest upgrade tracking PHPUnit/Pest internal churn), but it is recurring, not one-time. A reimplemented internal trait needs an initial port, a named owner, and a short internal doc.

Support. No vendor, no issue tracker, no CVE pipeline for the dev dependency. Internal documentation and a named owner are mandatory for any forked or reimplemented version. Security exposure is limited — it never ships to production — but it participates in lockfile resolution and should be pinned and reviewed like any other dependency. Onboarding docs must state explicitly that the package is archived and the internal replacement is authoritative, so it does not get re-added by the next engineer.

Scaling. Negligible runtime cost; it executes only in CI. The real scaling constraint is test-suite duration from Livewire component rendering itself, not the plugin. Parallel Pest runs (--parallel) are unaffected beyond normal Livewire test-isolation caveats — database transactions, event fakes, component state.

Failure modes.

• Composer resolution conflicts on pest, pest-plugin-api, or phpunit constraints.
• Pest 3 plugin auto-discovery changes causing silent non-registration ("livewire helper not found") without an obvious error.
• Trait method collisions with Livewire's native form assertions after a minor or major upgrade.
• Semantic drift producing false-green assertions after a Livewire upgrade — the highest-consequence failure, because it degrades trust in the entire suite.
• Typosquatted or republished package name surfacing during a lockfile refresh.
• Pinning pest ^1 / livewire ^2 in a service purely to satisfy the test helper — a governance smell that blocks other upgrades.

Ramp-up. A Laravel/Pest engineer reads the full API in under an hour; the surface is tiny and the idioms (livewire(), it(), dataset-driven validation tests) are familiar. The cost is governance and decision-making, not learning. The primary ramp-up risk is the inverse: an engineer unaware of its archived status adds it to a new service. Documentation must be authoritative, and removal should appear on the dependency review checklist.

How the TPM leverages this package.

• As a decision record: use it to justify a standing policy — dev helpers must be maintained, or owned internally.
• As a scope benchmark: it demonstrates that the "cheap middle tier" of headless, Pest-native component tests is where form-validation coverage belongs — shaping CI runtime budgets, flake tolerance, and per-sprint coverage commitments.
• As an ecosystem signal: its abandonment tells us the problem moved upstream. Deprioritize bespoke form-testing infrastructure; redirect that capacity into coverage patterns, test-data factories, and CI speed.
• As a reference implementation: the helper set is small enough to read as a spec for an internal trait we own.

Stakeholder framing.

• To executives: a very small, abandoned open-source helper for testing Livewire forms. No strategic value, some maintenance risk. Recommendation: do not adopt; if present, remove. The capability is now built into Livewire itself, so there is no gap to fill and no build cost to avoid. Cleanup is a day or two of engineering, with no customer-facing impact — not a roadmap item.
• To engineering: treat it as a signal, not a dependency. Use Livewire's native test helpers with standard Pest syntax; if we want nicer assertions or per-field validation output, write and own a small internal trait. Budget one to two days to audit and migrate any existing usage. No new adoption, no forking of the upstream repo, no version pinning — and a line in onboarding docs so it does not get re-added.