staudenmeir/dusk-updater
Keeps Laravel Dusk's browser drivers current: it adds an artisan command that downloads the latest ChromeDriver or GeckoDriver binary matching your installed browser, so Dusk tests keep working after browser updates. Handles Chrome and Firefox, version detection, and CI environments.
Architecture fit. staudenmeir/dusk-updater is developer tooling, not production runtime. It belongs in require-dev and in the CI test stage, and its single job is to keep the ChromeDriver/GeckoDriver binary bundled with Laravel Dusk aligned with the browser actually installed on a developer machine or runner. For a TPM this places the package in the test-infrastructure roadmap and build-vs-buy decision space: it substitutes for bespoke download/version-resolution scripts that Dusk teams otherwise end up writing and maintaining. v1.5.1 is a compatibility maintenance release (ChromeDriver 127+ support) with no architectural shift, so adopting it formalizes an existing need rather than committing the program to a new pattern. The opportunity score (35.83) sitting well above the overall adoption score (21.35) is the signal to read here: the underlying problem is real and recurring, but adoption is thin, so treat the package as a cheap targeted fix rather than a de facto standard.
Integration feasibility. Low for any team already running Dusk against Chrome/Chromium. The path is composer require --dev staudenmeir/dusk-updater, rely on Laravel package auto-discovery, and invoke php artisan dusk:update before php artisan dusk in local setup and in every CI job. The package also exposes a DuskUpdater facade, which matters if we drive a Chrome-version matrix programmatically or pin drivers for reproducibility. The real feasibility questions are environmental, not code-level: is Chrome present and detectable inside the CI image, is outbound HTTPS to the Chrome for Testing endpoints allowed, and does the runner architecture (x86/ARM/Apple Silicon/musl) have a matching binary.
Technical risk. Low-to-moderate and contained to test infrastructure — a failure degrades release confidence and developer velocity, not customers. The dominant risks are external: Google's Chrome/ChromeDriver release cadence and distribution endpoints, proxy/TLS egress rules, platform binary availability, and version detection inside containers where multiple Chrome installs may coexist. v1.5.1 closes one known failure class (Chrome 127+ driver resolution) but does not remove dependence on Google's distribution model. Secondary risk is supply-side: 124 stars, zero listed dependents, a single maintainer, and release metadata that is internally inconsistent (the listed last-release date, 2026-10-28, cannot be reconciled with a Chrome 127-era changelog) — all of which argue for tracking bus factor and verifying the actual tag history before pinning. Blast radius is small, so this is a monitored risk rather than a blocker.
Key questions.
dusk:chrome-driver already covers this and the package is largely redundant?Stack fit. Appropriate only for Laravel applications with Dusk-based end-to-end tests where Chrome/Chromium (or Firefox, via GeckoDriver) is the browser under test. It does not help Playwright, Cypress, Pest browser testing, cross-browser suites, or pipelines that already use managed Selenium Grid or Dusk-ready container images with drivers baked in. Treat it as a scoped, opt-in dev dependency for Dusk teams — not a fleet-wide standard — until the broader Dusk-versus-alternatives strategy is settled.
Migration path. New adoption: add as a dev dependency, run php artisan dusk:update, validate php artisan dusk locally and in CI, then document the step in the runbook and the CI setup snippet. Existing users upgrading: bump to ^1.5.1, refresh the driver binary, invalidate any cached vendor/laravel/dusk/bin artifacts, and re-run the full Dusk suite. No application code changes are indicated. Critically, if a team has already moved to Dusk 8+, the correct migration is away from this package onto the built-in dusk:chrome-driver — running both only overwrites the same binary and creates ambiguity about which mechanism owns driver resolution.
Compatibility. Treat v1.5.1 as a forward-compatibility update for Chrome 127+. Because framework ranges are not enumerated in the release notes, constraints must be verified against our Laravel/PHP matrix rather than assumed, and any code that vendors or subclasses the updater must move to ^1.5.1 (a hard pin to 1.5.0 will not resolve the 127+ fix). Platform compatibility is the sharper edge: Apple Silicon, ARM runners, and Alpine/musl images require different binaries, and the symptom typically surfaces as an execution failure rather than a download failure — which misroutes debugging unless the runbook calls it out.
Sequencing. Roll out on a branch: bump the package, clear cached driver binaries, run Dusk against the actual CI browser image, merge on green. Then coordinate with whoever owns CI images so the browser version and the updater version move together — an image bump that outruns the package reintroduces exactly the mismatch the package exists to prevent. For multi-repo adoption, sequence one representative repo first, publish the runbook and shared CI step, then replicate. Publish the change to engineering as a maintenance reduction, not a new platform commitment.
Maintenance. Low ongoing code maintenance: dev-only, purpose-built, no production surface. The real workload is tracking, not coding — keeping the package aligned with Chrome/ChromeDriver releases and with CI browser images. That obligation persists even when the package is stable, because Chrome ships on a roughly four-week cadence and will eventually outrun any pinned driver. Recommend a lightweight recurring dependency-review item (monthly is sufficient) and a named owner for browser-image updates so the two never drift apart unobserved.
Support. Support burden lands on CI/test-platform troubleshooting rather than application support. Most tickets read "Dusk broke this morning," and root cause is almost always browser/driver major-version drift, a wrong Chrome binary being detected in a container, blocked egress, or a stale cached binary — not a defect in the package. A short runbook covering install, the dusk:update step, explicit version pinning, cache invalidation, and a fixed debugging order (dusk:update -v → compare browser --version against driver --version) will absorb the majority. There is no vendor SLA and a single maintainer, so escalation paths are internal by definition.
Scaling. Scales technically across repos and parallel CI jobs but not cost-free: every fresh composer install rebuilds vendor/, so the update step must run on every job rather than being cached as a binary. Cache Composer's download cache; never cache vendor/laravel/dusk/bin. Parallel jobs must not race on a shared binary location unless isolated per job or container — otherwise expect intermittent, hard-to-reproduce failures that erode trust in the suite faster than a clean break would. At fleet scale, centralize the ordering constraint (browser install first, then updater) in one shared setup step or composite action rather than replicating it per pipeline.
Failure modes. Expect: major-version mismatch between detected Chrome and installed driver (dominant), multiple Chrome installs causing wrong-binary detection, unsupported platform/architecture combinations, blocked egress or proxy/TLS failures surfacing as resolution or 404 errors, a missing Chrome binary in the image, permission errors writing the binary, and stale caches after a Chrome upgrade. v1.5.1 removes the 127+ resolution failure from that list and does nothing for network, architecture, or environment causes. The TPM-relevant consequence is timing: these failures are noisy and land immediately before a release. Mitigate by running the update step in a pre-merge/pre-release smoke job rather than discovering drift during a release cut.
Ramp-up. Effectively zero for engineers already comfortable with Dusk — one command plus one documented CI line. Budget roughly half a day per repo for the first adoption (install, clear cached binaries, verify in CI, write the runbook entry) and a short team sync on the browser-image coordination rule. The harder ramp-up is organizational, not technical: establishing who owns CI browser images and how Chrome updates reach the fleet, without which the package's benefit is repeatedly undone by uncoordinated image changes.
How can I help you explore Laravel packages today?