Dust Laravel Package

Technical Evaluation

Resolve the artefact-identity conflict first — it is a gating step, not a footnote. The repository description, feature list ("Pest plugin for Laravel Dusk", "Dusk browser macros, assertions, screenshots"), and tagline all agree: pestphp/dust is a Pest↔Dusk test-syntax bridge. Prior write-ups in this pack that describe a dead-code scanner are built on the wrong premise and must be formally retired; none of their conclusions should feed this decision. A 30-minute source check (composer.json, src/, tests/) confirms or kills the premise before any money is spent. Everything below assumes the browser-testing interpretation.

Architecture fit. Narrow, non-invasive, and best framed as a standardization decision rather than a platform investment:

• Dev-dependency only. No runtime coupling, no schema, no service surface, no production blast radius. The footprint is composer.json, one Pest config entry, and CI config.
• Value is purely ergonomic. Dusk already drives a real browser; Pest already runs tests. This package unifies the syntax so unit, feature, and browser tests share one idiom. It adds zero testing capability.
• It only fits where Pest is already mandated and Dusk is already the chosen E2E mechanism. If either half is missing, the plugin bundles three decisions (adopt Pest, adopt Dusk, adopt this shim) into one small convenience — and the convenience does not repay that bundle.
• The real architectural question dwarfs the plugin choice: do we need browser E2E at all, and if so, is it Dusk-class or Playwright/Cypress-class? Settle that first; the plugin is a detail underneath it.

Integration feasibility. Mechanically cheap, operationally non-trivial:

• composer require --dev plus a config stanza, under a day to a first green test.
• The real cost is browser infrastructure in CI — headless Chrome, a driver (Dusk's bundled Chromedriver or a Selenium/standalone-Chrome container), cache dirs, failure artifacts. Budget 2–5 engineering days for a stable, non-flaky pipeline, not two hours.
• Dusk's own conventions (page objects, components, database/session handling, .env.dusk.*) must be learned regardless. The plugin changes how the test class is declared; it does not remove that curve.

Technical risk — high, driven by lifecycle status, not capability.

• Archived. No compatibility work for future Pest majors, no Laravel version support, no bug triage. Because the plugin hooks Pest's extension surface and Dusk's test-case bootstrapping — both of which have moved across majors — a frozen plugin is scheduled breakage, not a hypothetical.
• 13 stars, 0 dependents. Effectively no ecosystem validation. The team would be among the first serious users: no issue corpus, no Stack Overflow answers. Routine problems become original research.
• Two upstreams to track. Pest and Dusk churn independently; an archived plugin has no buffer against either.
• Flake is the dominant failure mode of browser testing generally. Paired with an unmaintained harness, the likely outcome is a suite that gets quietly skipped rather than fixed — the worst result, since it burns CI budget and returns no signal.

Key questions for the team.

1. Which artefact is this, confirmed from source? Produce the verification note before further spend.
2. Do we already run Dusk? If not, this is a much larger "do we need browser E2E at all?" decision and the plugin is a distraction.
3. Which Pest / Laravel / PHP versions are pinned, and is a Pest or Laravel major on the 12-month roadmap? If yes, treat adoption as scheduled breakage.
4. Expected test count: 10 or 300? Below ~20 the syntax-consistency benefit does not repay the dependency; above ~100 the maintenance exposure is material.
5. Does policy permit archived dev-dependencies, and is there a named owner with a fork-and-patch budget (hours/quarter)?
6. Does first-party support now cover this use case — i.e. has Pest or Dusk absorbed the ergonomics since this was archived? Confirm before adopting a frozen shim.

Recommendation: reject for new adoption. It buys syntax consistency and nothing else, and charges an unmaintained-dependency premium for it. If already in the codebase, treat it as a migration candidate with a documented exit, not a component to build on.

Integration Approach

Stack fit. Standard Laravel + Pest + Composer + GitHub Actions/GitLab CI, plus a containerized Chrome service. Acceptable only where Pest is the mandated runner and Dusk is the established E2E tool, and where Dusk page objects/components already exist — in that case the work is integration, not rewrite.

Migration path — run this as an evaluation, not an adoption.

1. Verification spike (½ day, timeboxed). Read the archived source, confirm function, composer require --dev on a throwaway branch, get one trivial Dusk test green locally.
2. CI prove-out (2–5 days). Wire headless Chrome in, capture screenshot/HTML on failure, and run the same single test 20 times to measure flake rate. A flaky harness is disqualifying regardless of syntax.
3. Port a bounded slice (1 sprint, one module). Convert 5–10 existing Dusk tests to Pest syntax. Record lines changed, engineer-hours, and any Dusk feature (page objects, components, waitFor, database migrations) that needed workarounds. Page-object compatibility is claimed — verify it.
4. Benchmark against the true baseline. The comparison is plain Dusk in PHPUnit style, not another tool. If the ported slice shows no meaningful reduction in authoring or review time, the plugin has no case — drop it and keep vanilla Dusk.
5. Go/no-go memo. One page: flake rate, porting hours, workarounds required, named owner, pinned version, exit triggers (e.g. "breaks on Pest major", "flake >5%").

Compatibility.

• Pin an exact version and commit the tested PHP × Laravel × Pest × Dusk matrix into the repo.
• Record the tested Chromedriver/Chrome pairing. Browser-driver skew is the most common silent breaker and it is invisible in composer.json.
• Schedule adoption away from any Pest or Laravel major. Do not land this in the same quarter as a framework upgrade — you will not be able to attribute failures.

Sequencing.

1. Source verification note (retire the conflicting assessments).
2. Product decision: is browser E2E in scope, and is it Dusk-based?
3. Local spike → CI prove-out → flake measurement.
4. Bounded module port, report-only in CI.
5. Only after a clean go/no-go: consider promoting to a blocking gate, on the narrow set of revenue-critical journeys (signup, login, checkout, onboarding) — never the whole suite.

Operational Impact

Maintenance. This is the dominant cost and it lands on the adopting team, permanently. No upstream fixes, no version-bump PRs, no security triage from the maintainer. Realistically budget a few engineer-hours per quarter for dependency drift plus an unbounded patch when a Pest or Laravel major lands. That is the true price of the syntax convenience, and it should be stated explicitly in the go/no-go memo. Compare it honestly against the alternative — vanilla Dusk in PHPUnit style, which is maintained and costs only stylistic inconsistency.

Support. No support channel. No issue corpus, no community answers at 13 stars and 0 dependents, no vendor relationship. Every non-obvious problem is original research by the owning engineer. That is tolerable for one engineer on one module; it is not tolerable as shared infrastructure that other teams depend on, because the knowledge concentrates in one person and becomes a bus-factor risk.

Scaling. Scales poorly and in a specific way: linearly in CI minutes and super-linearly in flake. Each browser test costs a full browser session; parallelism requires Dusk's own parallel infrastructure plus multiple Chrome containers, which the plugin neither provides nor improves. Concurrency, cross-browser matrices, network interception, video/trace artifacts, and visual regression are all outside its scope. Practical ceiling for this approach: a small-to-medium Laravel product with ~10–30 critical-path browser tests. Beyond that, the correct move is a maintained browser-automation tool, not more investment here.

Failure modes — plan for each explicitly.

• Silent skip (most dangerous). Flaky tests get @group-excluded or commented out; the suite stays green and delivers nothing. Mitigation: report-only mode with a visible flake-rate metric, and an alert when the browser suite's runtime or skip rate moves.
• Scheduled breakage. Pest or Laravel major lands; plugin no longer boots. Mitigation: pre-declared trigger for fork-and-patch versus rip-out, with a time budget and an owner named in advance.
• Driver/browser skew in CI. Chrome auto-updates past the bundled driver. Mitigation: pin both in the container image; pin the image tag.
• Environment drift. .env.dusk.*, test database, seeded fixtures, mail/queue fakes diverge from the app. Mitigation: treat Dusk env files as reviewed config, version them, and cover them with the same review discipline as app config.
• Trust erosion. A red browser build that nobody believes trains engineers to ignore red builds generally — the cost escapes the test suite and contaminates the whole pipeline's credibility.

Ramp-up. Two distinct curves. The mechanical one is short: a Pest-fluent engineer writes their first Dusk-in-Pest test in under a day. The effective one is long: stable selectors, explicit waits over sleeps, page-object structure, database/session isolation, and artifact-driven debugging typically take weeks to stabilize — and this is where the schedule actually slips. The plugin flattens none of that curve; it only changes how tests are declared. Onboarding new engineers to a single testing idiom (Pest everywhere) is a genuine, modest win, and it is the strongest argument in the package's favour.

Bottom line for the TPM. Frame this as a one-week, timeboxed, report-only spike on one module, with a written go/no-go based on measured flake rate and porting hours, and a documented exit — named owner, pinned version, and explicit abandonment triggers — agreed before merge. Do not let it become core CI infrastructure, and do not adopt it for new production work without a maintained-alternative review first.