Weave Code
Dust Laravel Package
pestphp/dust
A Pest PHP plugin that surfaces code gathering dust, flagging unused classes, methods, and other dead code in your Laravel or PHP project so you can safely clean it up right from your test suite.
A PHP browser testing solution using Laravel Dusk and Pest
Frequently asked questions about Dust
- What is pestphp/dust and what does it actually do?
- pestphp/dust is a Pest PHP plugin that bridges Pest to Laravel Dusk, letting you declare Dusk browser tests using Pest's test syntax instead of Dusk's PHPUnit-style class-based test cases. It adds no new testing capability: Dusk still drives the real browser and Pest still runs the suite. The value is purely ergonomic, so your unit, feature, and browser tests all share one idiom. It is a dev-only dependency with no runtime coupling, no schema, and no production surface.
- Is pestphp/dust a dead code scanner for unused classes and methods?
- No. That description is incorrect and has circulated in some write-ups by mistake. The repository description, feature list, and tagline all confirm pestphp/dust is a Pest-to-Laravel Dusk test-syntax bridge for browser testing. It does not analyse your source for unused classes, methods, or other dead code. Verify this yourself in composer.json, src/, and tests/ before spending time or money on it.
- How do I install pestphp/dust in a Laravel project?
- Install it as a dev dependency with composer require --dev pestphp/dust, then register the plugin in your Pest configuration and declare your browser tests using Pest's syntax. You still need Laravel Dusk itself installed and configured, including a working browser driver and .env.dusk.* environment files. Mechanically it is a composer line plus a config stanza, and a first green test is usually achievable in under a day. The real effort is browser infrastructure in CI, not the package install.
- Which Laravel, Pest, and PHP versions does pestphp/dust support?
- The package pins its supported Pest, Laravel, and PHP ranges in composer.json, and you should read that file directly rather than assuming. Because the project is archived, no compatibility work is being done for future Pest or Laravel majors, so the supported matrix is frozen at whatever was current when it was last touched. If a Pest or Laravel major release appears on your twelve-month roadmap, treat adoption as scheduled breakage and budget a fork-and-patch owner.
- Is pestphp/dust still maintained?
- No, the repository is archived, with roughly 13 stars and zero dependents, so there is no bug triage, no issue corpus, and no upstream compatibility work. That matters more than usual here because the plugin hooks Pest's extension surface and Dusk's test-case bootstrapping, both of which have shifted across majors. A frozen plugin in that position is a scheduled breakage rather than a hypothetical risk. Confirm your organisation permits archived dev-dependencies and name an owner with a repair budget before adopting.
- Do I still need Laravel Dusk installed to use pestphp/dust?
- Yes. pestphp/dust is a thin syntax layer and does not replace Dusk, Chromedriver, or any part of the browser automation stack. You must already have Dusk installed, a browser driver available, and Dusk's page objects, components, and database/session conventions learned. The plugin changes how a test class is declared; it does not remove the Dusk learning curve.
- What does the CI setup for pestphp/dust browser tests require?
- You need headless Chrome, a driver such as Dusk's bundled Chromedriver or a Selenium or standalone-Chrome container, writable cache directories, and stored failure artifacts like screenshots and console logs. Budget two to five engineering days for a stable, non-flaky pipeline rather than a couple of hours. Flakiness is the dominant failure mode of browser testing, and with an unmaintained harness the usual outcome is a suite that gets quietly skipped rather than fixed.
- How does pestphp/dust compare to plain Laravel Dusk or Playwright and Cypress?
- Against plain Dusk the difference is syntax only: same browser, same assertions, same screenshots, just Pest-style test declarations instead of PHPUnit classes. Against Playwright or Cypress the comparison is not really about this package at all, because those are a different class of end-to-end tooling with different language and runtime trade-offs. The architectural question to settle first is whether you need browser E2E at all and, if so, whether it should be Dusk-class or Playwright/Cypress-class; the plugin choice is a detail underneath that.
- Will pestphp/dust break when I upgrade Pest or Laravel?
- It is likely, because the plugin depends on Pest's extension surface and Dusk's test-case bootstrapping, both of which have moved between majors. With the repository archived there is no buffer against churn in either upstream, and you would be tracking two independently moving projects on your own. Pin your Pest, Laravel, and PHP versions and treat any major upgrade as a task that includes patching or replacing this package.
- Should I adopt pestphp/dust for a small browser test suite?
- Probably not. Below roughly twenty browser tests the syntax-consistency benefit does not repay the added dependency, and above roughly a hundred the maintenance exposure against an archived plugin becomes material. It only makes sense where Pest is already mandated and Dusk is already your chosen E2E mechanism, in which case it bundles no new decisions. If either half is missing, it quietly bundles three decisions into one convenience, and the convenience rarely justifies that.
Weaver
How can I help you explore Laravel packages today?