Dusk Updater Api Laravel Package

Product Decisions This Supports

• Build vs. buy for test-infrastructure plumbing. This package answers a narrow "buy" question: rather than owning ChromeDriver version-resolution logic, you consume a small library that exposes ChromeVersionFinder and ChromeDriverDownloader. It does not answer the larger build-vs-buy question, because the orchestration layer — CLI command, config, caching, platform detection, retries — is not shipped. Budget the wrapper as internal build work and treat the package as one ingredient, not the deliverable.
• Feature scoping for CI reliability work. Use it to decide whether "end-to-end tests stop working when Chrome auto-updates" is a real roadmap item with recurring cost (roughly a four-week Chrome release cadence) or a one-off fire. If it recurs, this package is a candidate input to a durable fix; if it's one-off, a pinned driver in the CI image is cheaper.
• Roadmap triage against the default path. Current laravel/dusk already resolves and downloads a compatible ChromeDriver via dusk:install / dusk:update. Adopting this creates a second source of truth for driver versions. The honest framing for prioritisation: this package only earns a sprint slot where the native path is genuinely blocked — air-gapped or proxy-restricted CI, pre-baked container images, multi-arch builds, or centralised driver caching across many pipelines.
• Use-case validation gates. It supports a decision to standardise driver provisioning inside those specific pipelines, not organisation-wide. Zero dependents and a 2.1 composite score mean there is no external evidence of production or CI use to point at when justifying broader rollout.
• Vendor/supply-chain risk decisions. It forces an explicit decision on a security-relevant question: you are shipping a library whose entire purpose is downloading executables, with no documented integrity verification, endpoint disclosure, or security policy. A PM decision here is whether that is acceptable for dev-only tooling (defensible) versus anything on the critical path to production (not defensible).
• Exit-strategy planning. Because the wrapper is thin, the decision can be made cheaply and reversed cheaply — replacing the package with direct calls to Chrome-for-Testing JSON endpoints is a contained change of a few dozen lines. That reversibility is itself a product asset and should be used to de-risk approval.

When to Consider This Package

Consider it when all of the following hold:

• You run Laravel Dusk in a controlled, containerised or image-baking environment where you want explicit, deterministic control over which ChromeDriver binary lands on disk.
• The native Dusk path is insufficient for a concrete, named reason: air-gapped CI, proxy restrictions, multi-architecture fleets (arm64, Alpine/musl, Windows), or a desire to cache drivers centrally rather than re-download per pipeline.
• You are replacing bespoke shell scripts that wget a hardcoded, frequently stale ChromeDriver URL. This is the strongest case — dynamic version resolution is a real reliability gain and the surrounding wrapper barely changes.
• You have an owner identified for the wrapper and are willing to treat the package as an unsupported upstream component with first-line support handled internally.
• You can pin the exact version and have verified its composer.json constraints against your PHP, Laravel, Guzzle, and Symfony Process versions rather than trusting release notes (the Guzzle 8 claim in v1.0.6 is exactly the kind of thing to confirm in the lockfile).

Look elsewhere — or simply stay put — when:

• Your local and CI environments already work via php artisan dusk:install. Adopting this adds a dependency and removes no work.
• You need a turnkey Artisan command. That layer was in the predecessor orchestra/dusk-updater and was deliberately removed; migrating from it is conceptual, not a drop-in swap.
• Single maintainer, no SLA, no security policy, no compatibility matrix, and no documented retry/timeout/proxy/mirror/checksum behaviour are disqualifying for your risk posture.
• You are in a large monorepo with a shared lockfile and cannot absorb a widening transitive footprint (orchestra/sidekick since v1.0.2; Guzzle 8 and Symfony Process 8 support) without lockfile-conflict risk.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost, easily reversible utility that could fix a recurring CI annoyance — end-to-end tests breaking whenever Chrome updates — but only for a narrow set of pipelines. It adds no new capability over what Laravel Dusk already does by default, and it comes with real but contained risk: a single maintainer, no published support or security policy, and a job that literally downloads executables. Recommendation: approve a short spike and a thin internal wrapper for one or two pipelines, run it in shadow mode alongside existing provisioning for a couple of months, and do not make it a platform standard until it has survived at least one Chrome major-version cycle.

For engineering: Mechanically trivial — Composer --dev dependency, PSR-4 classes, no service provider needed for basic use. The real cost is everything the package does not supply: no CLI, no config, no version-compatibility matrix, and a README that states the purpose and stops. You will design and own version comparison, download paths, caching, platform detection, and retry/timeout behaviour. Encapsulate the package behind an internal service or Artisan command so its API never leaks into pipelines, pin the package and transitive HTTP client versions, and keep the wrapper thin enough that swapping in direct Chrome-for-Testing JSON calls stays a contained change.

For security and platform review: Flag this explicitly. Before any adoption, confirm what is downloaded, over what transport, from which endpoint, and whether integrity is verified before execution — the README and release notes are silent. Also confirm behaviour on every architecture in the fleet (silent no-result on arm64, Windows, or Alpine/musl is a plausible failure mode) and whether the wrapper and Dusk are contending for the same vendor/laravel/dusk/bin path.

Decision ask: Approve as an evaluated option behind a project-owned wrapper, scoped to the pipelines that motivated the change. Do not adopt as a platform standard. Named owner for the wrapper is a precondition; a spike that resolves and runs the exact Chrome version used by the CI image is the first gate.