Dust Laravel Package

Product Decisions This Supports

• How much E2E coverage is worth buying. The real PM decision is which user journeys deserve real-browser tests versus unit and feature tests. pestphp/dust does not answer that question — it only lowers the cost of acting on the answer for teams already on Pest. Frame it as a discount on a pre-existing decision, not a reason to make one.
• Test tooling strategy: build vs. buy vs. assemble. The comparable options are plain Laravel Dusk, a Pest-native wrapper over Dusk, a Playwright/Cypress-class tool, or a paid cross-browser grid. This package is a thin ergonomics layer over Dusk and competes purely on developer fit — it adds no capability Dusk lacks. A PM should treat it as a convenience for a Pest-standardized shop, never as a QA platform selection.
• Release-gate policy. Whether browser tests block a release, run nightly, or report only is a product policy call about what is allowed to stop a ship. The package only changes how cheap those tests are to author — it should not change the gate itself.
• Upgrade and refactor confidence. Its clearest product value is as a safety net during Laravel, PHP, or Pest majors, and during refactors of navigation, auth, or shared layout. A small set of real-browser smoke tests turns "we hope checkout still works" into a verifiable claim.
• QA maturity roadmap. It gives a small team a credible first rung from manual regression → automated smoke on critical flows → broader E2E, without headcount or a vendor contract. Useful for sequencing investment, not for justifying a large one.
• Living documentation of user journeys. Dusk page objects and components map naturally onto product journeys, giving PM, design, and engineering a shared artifact for scope and acceptance criteria, and shortening onboarding.
• Dependency governance — a decision in its own right. Archived, 13 stars, 0 dependents. That is not a blanket blocker for a bounded spike, but it forces an explicit choice: adopt-with-exit-plan, fork-and-maintain, or replace with something maintained. Never let it become core CI infrastructure by default.
• Use-case validation. Best fit is a small-to-medium Laravel product already on Pest with a short list of revenue-critical flows. Poor fit for multi-team products needing a browser matrix, parallelism at scale, network mocking, visual regression, or a supported vendor relationship.

When to Consider This Package

First, verify what the package actually is — this is a gating step, not a formality. The repository describes a Pest plugin for Laravel Dusk browser testing; some internal write-ups in this pack describe a dead-code scanner. Those are different products with different costs and risks. A one-hour source check (composer.json, src/, tests/) settles it, and any assessment written against the wrong premise should be formally retired. Everything below assumes the browser-testing interpretation, which matches the repository's own documentation.

Consider it when:

• The product is a Laravel app already standardized on Pest, so Dusk is an extension of an existing habit rather than a second toolchain.
• The need is real-browser coverage of a small, stable set of critical journeys — signup, login, checkout, onboarding — not a comprehensive E2E suite.
• The team wants browser tests to live inside the existing Pest suite and CI, with familiar syntax and expectations.
• Dusk page objects and components already exist, making this integration work rather than a rewrite.
• The budget is a timeboxed spike — roughly 1–3 days to a first stable CI signal, longer to quell flakiness — not a funded QA initiative.
• The package is already in the codebase and the near-term goal is to understand, stabilize, or migrate existing usage.
• The team accepts ownership of compatibility and has a documented exit path before merge.

Look elsewhere when:

• The product is new, long-lived, or multi-team and needs a maintained dependency with version support and an upgrade path.
• You need a cross-browser or device matrix, parallel execution at scale, video/trace artifacts, network interception, or visual regression — Playwright-class tooling or a commercial grid fits better.
• The front end is a heavy SPA or a non-Laravel stack, where Dusk's Laravel-centric model adds friction instead of removing it.
• The team is not on Pest; adopting a runner plus an archived plugin costs more than it returns.
• Policy requires supported dependencies, security triage, clear ownership, or an SLA — archived dev-dependencies routinely fail that bar.
• Flakiness tolerance is low. A slow, intermittently failing browser layer teaches engineers to ignore red builds, and that trust cost exceeds the value of the tests.

Given archived status, near-zero adoption, and zero dependents, this should not be adopted as core CI infrastructure for new production work without a timeboxed reason and a named owner.

How to Pitch It (Stakeholders)

Executive summary: pestphp/dust is a small MIT-licensed plugin that lets a team write Laravel Dusk real-browser tests in Pest's syntax. Its value is ergonomic: for a product already standardized on Pest, it lowers the cost of automating a handful of critical user journeys and gives framework upgrades a safety net. Its risk is supply chain: it is archived, has 13 stars and no dependents, so version support is frozen and the team would own every future Laravel and Pest upgrade. Recommendation: treat it as a tactical convenience for a bounded effort, not a platform commitment, and only after confirming from source what the package actually does.

Engineering summary: A thin Pest integration over Laravel Dusk — dev-dependency only, no runtime or infrastructure footprint, no production blast radius. Fits cleanly where Pest is the mandated runner and Dusk page objects already exist. Installation is trivial; the real cost is calibrating selectors and flakiness, which typically outlasts the spike itself. Because the package is unmaintained, pin an exact version, record the tested PHP × Laravel × Pest matrix in the repo, and schedule adoption away from any Pest or Laravel major upgrade. It sits alongside PHPUnit feature tests and static analysis rather than replacing them — it adds browser-level coverage and nothing else.

Product recommendation: If the team is on Pest and the goal is fast, low-cost smoke coverage of a few revenue-critical journeys, run a one-week timeboxed spike on a single module, report-only in CI, with a written go/no-go based on false-positive and flakiness rates. Do not land a blocking browser gate in the same quarter as a framework or Pest major upgrade. Document the exit before merge — named owner, pinned version, and explicit abandonment triggers such as "breaks on next Pest major" or "flake rate above 5%". If the need is broader than a handful of flows, or if the dependency must be supported for years, choose a maintained browser-automation tool instead and retire this decision entirely.