Dusk Updater Laravel Package

Product Decisions This Supports

• Build vs Buy: Eliminates the need to build/maintain custom ChromeDriver update scripts, leveraging a maintained package to resolve driver/browser version drift instead of owning that code path.
• Test infrastructure investment: Keeps end-to-end (Dusk/browser) test suites green without scheduled manual intervention — a recurring CI maintenance cost that is easy to underestimate and hard to staff.
• Roadmap sequencing: Removes a blocker to expanding browser-based regression coverage (more specs, more browsers) because driver provisioning stops being a per-environment chore.
• Dependency hygiene (v3.2.0): Adding Guzzle 8.0 support signals the package tracks current HTTP client majors, so adopting it does not pin the rest of the application to an older Guzzle line. This matters for teams already on — or planning to move to — current Laravel releases, where a transitive Guzzle 7 constraint would otherwise force a conflict or a fork.
• Vendor risk / maintenance signal: A release landing promptly after a Guzzle major is evidence of active stewardship; useful input when comparing against a one-off internal script that has no owner.

When to Consider This Package

Adopt when most of the following hold:

• The application runs browser/end-to-end tests through Laravel's tooling (Dusk or an equivalent driver-based setup) in CI.
• Browsers in CI are updated automatically or run in images that move (so driver/browser mismatches are a live failure mode).
• The team wants no dedicated owner for test-infrastructure plumbing, and no desire to hand-roll download, cache, and platform-detection logic.
• The stack is on a current PHP/Laravel combination and an up-to-date Guzzle major — v3.2.0 is the release that makes this combination clean; older pins of the package may conflict.
• Environments can reach the driver download source, or you have a mirror/artifact cache.

Look elsewhere when:

• Browser testing is built on Playwright, Cypress, or a Selenium Grid you operate — driver lifecycle is already handled outside the PHP process.
• Builds are fully air-gapped with no artifact mirroring, so an automated download step is a liability rather than a convenience.
• You need a vendored, version-pinned driver for reproducibility/compliance audits, where unpinned auto-updates are unacceptable.
• The stack is on a framework version this package no longer supports, or is locked below Guzzle 8 with no upgrade path — in that case stay on the prior package line rather than forcing an upgrade.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk dependency that removes a recurring source of broken builds. Today, when a CI machine picks up a new Chrome version, our browser tests fail until someone manually patches the driver — unplanned work that blocks merges. Buying this (as a free, permissively licensed package) retires that class of outage and the on-call burden that comes with it, at essentially zero cost versus maintaining our own script. The latest release simply keeps us compatible with current Guzzle, so adopting it doesn't constrain our upgrade plans.

For engineering: Drop-in replacement for our in-house driver-update logic; no application code changes and no API surface to learn. v3.2.0 adds Guzzle 8 support — a compatibility release, not a breaking one — so it's the version to target if we're on a current Guzzle major, and it removes a potential dependency conflict before it reaches composer update. Recommend piloting on one pipeline, measuring flake rate and CI minutes for two sprints, then rolling out and deleting the custom script.