Pest Plugin Livewire Laravel Package

Product Decisions This Supports

• Build vs. buy vs. skip for internal tooling. The relevant "product" here is not a feature but a testing capability: how cheaply can engineers write trustworthy tests for Livewire forms? The package is a thin DX layer over Livewire's own test API (livewire() mount helper, chainable assertions, Pest expectations), which makes this a three-way call — adopt the plugin, hand-roll a ~50–150 line internal trait, or use Livewire's native helpers as-is. On any Livewire 3 codebase the honest answer is the third, which reframes the package as a reference point rather than a decision to make.

• Coverage strategy and where test budget goes. Teams shipping Livewire-heavy surfaces — admin panels, onboarding, settings, checkout — constantly arbitrate how much form behavior to pin down in fast headless component tests versus slow browser E2E. Tooling like this defines the cheap middle tier: Pest-native, sub-second, CI-friendly. That directly informs the coverage promise we can make per sprint, our CI runtime budget, and our tolerance for flake.

• DX investment and who writes tests. Pest's it() / expect() idioms lower the bar for product engineers to own their own component tests. Whether we standardize on Pest-flavored form assertions shifts the ratio of tests written by feature teams versus QA — a real lever on cycle time and release confidence, not a cosmetic preference.

• Dependency governance and legacy modernization. This is the sharpest product signal: archived upstream, zero stars, zero dependents, last release April 2023, and it predates Livewire 3, Pest 2/3, and modern PHPUnit internals. As an input to dependency review the verdict is simple — do not introduce. If it already exists in a legacy service, queue removal alongside the next Livewire/Pest upgrade. Low effort, no customer-facing impact, removes a small but non-zero supply-chain and false-green risk.

• Ecosystem signal for the roadmap. Its existence and abandonment tell us the problem has been absorbed upstream. Roadmap implication: stop budgeting for bespoke form-testing infrastructure. Redirect that capacity into coverage patterns, test-data factories, and CI speed — the things that actually gate shipping.

• Upgrade-path risk framing. The most expensive failure mode isn't a broken test, it's a false-green one — helpers that keep passing against drifted Livewire semantics and quietly erode trust in the whole suite. That risk belongs in any upgrade business case that touches Livewire or Pest versions.

When to Consider This Package

Reasonable only in a narrow legacy context:

• You are pinned to Livewire 2.x with Pest 1.x — the combination it was built for — and want Pest-style form assertions without writing helpers yourself.
• You are prepared to vendor or fork it, accepting that upstream is archived and will ship no compatibility fixes, patches, or triage.
• You have a small, well-understood set of form components and no near-term plan to upgrade the stack.

Look elsewhere when:

• You are on Livewire 3+, where fillForm, assertFormSet, assertHasErrors, and assertHasNoFormErrors cover the same ground with no added dependency.
• You need maintained tooling: no releases since April 2023, no dependents, no active maintainer. Upgrade risk and supply-chain exposure outweigh convenience.
• Your gaps are end-to-end — real browser behavior, JS interactions, uploads. That's Dusk, Playwright, or Cypress territory, not component helpers.
• You want longevity with minimal surface area: a small internal trait around Livewire's native test API is cheaper to own than an abandoned package, and you control the upgrade path.

How to Pitch It (Stakeholders)

To executives: This is a very small, abandoned open-source helper for testing Laravel Livewire forms. It carries no strategic value and a modest amount of maintenance risk. Recommendation: do not adopt. The capability it offered is now largely built into Livewire itself, so there is no product gap to fill and no build cost to avoid. If it exists anywhere in our codebase, removing it is a low-effort cleanup with no customer-facing impact — roughly a day or two of engineering, not a roadmap item.

To engineering: Treat this as a signal, not a dependency. It confirms that Livewire form testing is a solved problem at the framework level — use Livewire's native helpers with standard Pest syntax, and if we want nicer assertions or per-field validation output, write a small internal trait we own and control. Budget one to two days to audit for existing usage and migrate those assertions; no new adoption, no forking, no version pinning. Add a line to onboarding docs stating the package is archived and the internal replacement is authoritative, so it doesn't get re-added during the next composer require.