Dusk Updater Laravel Package

Product Decisions This Supports

• Test-strategy roadmap: If Laravel Dusk end-to-end coverage is being considered, dusk-updater removes a recurring operational objection—Chrome auto-updates and browser tests fail on driver version mismatch. It lets the team evaluate Dusk on test value rather than driver-maintenance pain.
• Build vs. buy: Buy, at near-zero cost. Do not staff an internal backlog item for ChromeDriver download/version-resolution scripts. Adopt this as a require-dev dependency and redirect engineering time to product work. Important caveat: Dusk 8+ already ships a dusk:chrome-driver command, so this is a buy decision mainly for older Dusk versions, pinned-driver workflows, or multi-version browser matrices—not a universal requirement.
• Release cadence and CI reliability: Chrome updates on hosted runners and can break Dusk runs unpredictably. Reliable Dusk execution supports faster, safer releases of customer-facing Laravel features and reduces “green build, red build” churn that erodes trust in CI. v1.5.1’s ChromeDriver 127+ support is a forward-compatibility signal that the package tracks Chrome’s release cadence.
• Environment standardization and onboarding: Standardizing local and CI browser-test setup around php artisan dusk:update reduces “works on my machine” failures and shortens ramp-up for engineers joining a Laravel codebase.
• Use cases: Laravel applications with Dusk browser tests; CI pipelines running Chrome/Chromium or Firefox/GeckoDriver; teams that auto-update browsers and need matching drivers without manual intervention; jobs that must pin a specific driver version for reproducibility; multi-version browser matrices driven programmatically via the DuskUpdater facade.

When to Consider This Package

Consider it when most of these are true:

• You run Laravel Dusk browser tests against Chrome/Chromium or Firefox/GeckoDriver locally or in CI.
• Your team spends time manually refreshing drivers, debugging “this version of ChromeDriver only supports Chrome version N” errors, or maintaining custom download scripts.
• You are on a pre-Dusk-8 version, need to pin a specific driver version, or want to install drivers for several browser versions in one job.
• You have acceptable network egress to Chrome-for-Testing/GeckoDriver endpoints, or can configure proxies.
• You accept a small, community-maintained MIT package as a dev-only dependency and do not require an SLA or vendor security guarantee.
• You value reduced CI flakiness and developer toil over owning browser-driver infrastructure.

Look elsewhere if:

• You do not use Laravel Dusk, or you use Playwright, Cypress, Pest browser testing, or another stack with its own driver management.
• You are on Dusk 8+, where dusk:chrome-driver already covers this. Running both just overwrites the same binary and creates ambiguity about which mechanism owns driver resolution.
• You need broad cross-browser coverage beyond local Dusk Chrome/Firefox drivers, commercial support/SLAs, or formal vendor security guarantees.
• Your CI already uses container images or managed services that bundle and maintain browser drivers, such as Dusk-capable Docker images or Selenium Grid.
• Your organization restricts third-party dev dependencies or requires formal maintainer/security review for test tooling.

How to Pitch It (Stakeholders)

For executives: This is a developer-productivity package, not a customer-facing feature. It keeps Laravel browser tests running as Chrome updates on its own, so releases do not slip because of test-infrastructure failures. v1.5.1 is a maintenance release adding ChromeDriver 127+ support—no breaking changes—and signals active upkeep. Cost is effectively zero; the return is fewer CI interruptions, more reliable release confidence, and engineering hours returned to product work instead of maintaining browser-driver scripts. Scope is deliberately narrow: it matters only if we invest in Dusk-based end-to-end testing, and it does not replace a broader browser-test strategy.

For engineering: Adopt staudenmeir/dusk-updater as a require-dev dependency if you run Dusk against Chrome and are on a Dusk version that predates the built-in dusk:chrome-driver command, or if you need to pin driver versions. Install it, then add an explicit php artisan dusk:update step to CI after the browser is installed and before php artisan dusk. The driver binary in vendor/ does not survive composer install, so the update step must run on every fresh CI job. Pin a version explicitly where reproducibility matters, and pin the matching browser build too or the pin drifts. Watch the usual failure modes: browser major-version mismatch from multiple installs, ARM/Apple Silicon/Alpine binaries, blocked downloads behind proxies, permission errors writing the binary, stale caches, and version detection inside containers. Run the update inside the container Dusk uses. If you are on Dusk 8+, prefer the built-in command and drop this package. Treat v1.5.1 as a low-risk forward-compatibility bump; confirm Composer constraints against your Laravel/PHP/Dusk matrix, then roll out behind a branch with a full Dusk run.