Laravel Dusk Firefox Laravel Package

Product Decisions This Supports

• Cross-browser quality strategy. Dusk defaults to Chrome/ChromeDriver; this package swaps in Firefox via GeckoDriver. Use it when "we only ever test in Chromium" is a risk you've decided to close — e.g. consumer-facing products with meaningful Firefox traffic, or JS-heavy flows (checkout, auth, file upload) where engine differences surface as real defects.
• Test infrastructure and CI economics. A supported Firefox driver path is an alternative when Chrome/ChromeDriver is awkward in your CI images, locked-down runners, or container base images. Relevant to build-vs-buy on test tooling: buying a maintained adapter beats an in-house Dusk/GeckoDriver shim.
• Vendor concentration on Chrome. If procurement or platform decisions push you to avoid a single browser vendor in the delivery pipeline, this is a cheap, reversible hedge confined to the test suite.
• Roadmap gating for browser support claims. Supports (or blocks) marketing/support statements like "verified on Firefox." Only commit to such claims once the suite runs green against Firefox in CI, not just developer machines.
• Upgrade sequencing for Laravel 11. v3.0.0 adds laravel/dusk:^8.0 support and is the release that makes this package viable on current Dusk. Plan this alongside your Laravel 11 / Dusk 8 upgrade, not after it.

When to Consider This Package

Adopt when:

• You already use Laravel Dusk and want Firefox coverage without hand-rolling driver configuration.
• You are on Dusk 8 (this release's requirement); older Dusk lines need an earlier major of this package.
• Firefox/Gecko-based testing is a stated quality goal, a CI environment constraint, or a customer/contract requirement.
• You can absorb a small, community-maintained dependency in dev dependencies only — blast radius is the test suite, not production.

Look elsewhere when:

• You are standardized on Chrome and have no Firefox requirement — native Dusk is simpler and has one fewer dependency to track.
• You need broad multi-browser coverage (Safari/WebKit, mobile emulation, device farms); a driver adapter is not a cross-browser platform. Evaluate hosted grids or Playwright/Cypress-class tooling instead.
• You need a vendor SLA, security review, or guaranteed release cadence — assess maintainer activity and pin versions deliberately.
• Your suite has outgrown Dusk entirely (parallelism at scale, flake budgets); switching drivers won't fix that.

Upgrade note for v3.0.0 (breaking). Laravel 11 apps that removed tests/CreatesApplication.php must regenerate the Dusk scaffold, because the shipped tests/DuskTestCase.php still references the deleted CreatesApplication trait. One command resolves it:

• php artisan dusk:install-firefox, or
• php artisan dusk:install-firefox --with-chrome

Treat this as a local, committed change to test scaffolding, not a runtime migration: schedule it in the same sprint as the Dusk 8 bump, expect any local DuskTestCase customizations to need re-applying, and verify CI green before merging. No data, API, or user-facing impact.

How to Pitch It (Stakeholders)

To executives: A small, low-risk addition to our test tooling that lets us verify the product in Firefox as well as Chrome. It is a development-only dependency — it never ships to customers, and removing it is a one-line reversal. Cost is a short upgrade task, not a project.

To engineering: Adopt on Dusk 8 only; v3.0.0 adds that support and includes a breaking step — regenerate tests/DuskTestCase.php with php artisan dusk:install-firefox (add --with-chrome to keep Chrome configured too) if we deleted CreatesApplication.php under Laravel 11. Re-apply any local customizations to that file, pin the version, and gate the merge on a green Firefox CI run.

Recommendation: Adopt if Firefox coverage or CI flexibility is on the roadmap and we are on Dusk 8; otherwise defer. Keep native Chrome Dusk as the documented fallback so the decision stays cheap to reverse.