Mink Selenium2 Driver Laravel Package

Product Decisions This Supports

• Build vs. buy for browser-level acceptance testing. This package is the plumbing that lets a PHP test suite (Behat/Mink) drive a real browser via WebDriver. If your roadmap includes end-to-end coverage of user journeys — login, checkout, multi-step forms, JS-driven UI — this is the layer that makes it possible without writing a bespoke WebDriver client.
• Test strategy and QA investment sizing. Choosing a Mink-compatible driver commits you to a specific CI shape: a Selenium/ChromeDriver service, headless browser containers, retry/rerun logic for flaky specs, and screenshot-on-failure artifacts. That is a real budget line, and it belongs in the same conversation as headcount for QA automation.
• Fork vs. upstream governance. This is a low-signal distribution (2 stars, 0 dependents) of a capability that already exists upstream under behat/mink-selenium2-driver. The PM decision is less "adopt this" and more "do we knowingly take on a vendor fork, and who owns the delta?" Treat the fork as a patch-carrying artifact: if Lullabot is shipping fixes your stack needs before upstream merges them, that is a legitimate, time-boxed reason to depend on it — with an explicit exit plan.
• Drupal/PHP shop standardization. For teams already in the Lullabot/Drupal orbit — Drupal contrib module testing, Behat-based acceptance suites, legacy PHP monoliths — this is a plausible "known-good with our stack" choice that reduces integration discovery work.
• Supply-chain and maintenance risk register. A package with no dependents and a single maintainer org is a concentration risk. It should appear on your dependency-risk review alongside license (MIT-compatible), release cadence, and bus factor, not be quietly pulled in by an engineer's composer require.
• Deprecation/exit planning. If you already depend on it, the decision this supports is migration timing: track the diff against upstream and schedule removal once your patches land there.

When to Consider This Package

Adopt only when most of the following are true:

• You are already committed to Mink + Behat (or a framework wrapping it, e.g. Drupal's test runners, Codeception's Mink bridge) and need real-browser WebDriver execution.
• You have a specific, named reason to prefer this fork over upstream — a merged-but-unreleased fix, a Drupal-specific patch, or an existing internal dependency on the Lullabot distribution. "It was in the tutorial" is not a reason.
• You can verify the diff: read the fork's commits against behat/mink-selenium2-driver and the underlying php-webdriver/webdriver version constraint. If the delta is empty or stale, the fork has no value and upstream is strictly better.
• You have someone who owns the dependency — a named engineer who will watch releases, patch CVEs, and re-point to upstream when possible.
• Your CI can host the browser infrastructure the driver assumes (Selenium Grid or a compatible endpoint, matching driver/browser versions).

Look elsewhere when:

• You want community support and documentation. Upstream behat/mink-selenium2-driver has the issues, the Stack Overflow answers, and the release history. This fork has neither.
• You need a maintenance guarantee. Stars, dependents, and release history are all thin; there is no SLA and no evidence of broad production usage beyond the maintainer's own client work.
• You're not already on Mink. For greenfield projects, Playwright (via Node or the PHP bridges) or Cypress will usually beat a PHP-WebDriver stack on speed, debugging ergonomics, and auto-waiting — and they remove an entire CI service from your architecture.
• You're on modern Symfony/PHPUnit-only stacks. Symfony's Panther or PHPUnit's browser abstractions may cover the need with fewer moving parts.
• You need a decision this quarter. Validating a low-adoption fork costs more calendar time than the capability is worth.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed testing utility, not a product dependency. It lets our PHP test suite drive a real browser so we can catch regressions in user-facing flows before customers do. The capability is worth having; this particular distribution is not the safest carrier for it. Recommendation: adopt the upstream, community-maintained driver by default, and only use this fork if engineering can name the specific fix it provides — in which case we time-box it with a documented exit to upstream. Cost is low; the real investment is CI browser infrastructure and ongoing flake triage, which we should size before committing to end-to-end coverage as a roadmap item.

To engineering: Treat lullabot/mink-selenium2-driver as a fork with no ecosystem around it — 2 stars, zero dependents. Before anyone adds it to composer.json, produce the commit diff versus behat/mink-selenium2-driver and confirm the php-webdriver version constraints. If the diff is empty or the fork lags upstream, use upstream. If we do take it, pin the version, document the reason in the repo, and add the removal ticket the same day.