Laravel Browser Kit Macro Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing. Decides whether a Laravel 5.3 → 5.4+ (or later) upgrade ships with the existing test suite intact, or whether the upgrade is gated behind a test-suite rewrite. This macro lets you decouple those two workstreams.
• Runtime upgrade sequencing (new). The 5.9.0 release adds PHP 8.5 support, which means the shim no longer pins you to an older PHP runtime. This turns a two-way decision (upgrade Laravel or upgrade PHP) into a decision you can make independently, and removes PHP version as a blocker on the framework upgrade path.
• Build vs. buy for internal tooling. The alternative is writing a compatibility macro in-house (a day or two of engineering, plus ongoing ownership). This package is a buy (adopt) decision with near-zero cost and near-zero lock-in.
• Test strategy standardization. Preserves $this->visit() / $this->see() / assertion-style BrowserKit tests across versions, so QA and engineering keep one mental model instead of running two testing paradigms during a migration window.
• Legacy maintenance budgeting. Signals whether the team invests in modernizing tests (Pest, HTTP tests, Laravel Dusk) or defers that cost by keeping the old API shimmed. Useful input for roadmap capacity planning on a legacy monolith. The 5.9.0 PHP 8.5 support raises the risk of indefinite deferral — the shim keeps working, so the rewrite ticket keeps slipping. Budget for it explicitly rather than letting compatibility do the deciding.
• Risk register / dependency policy. With ~2 stars and 0 dependents, upstream ecosystem pull remains negligible. The 5.9.0 release is the first evidence of maintenance beyond the original author (a new outside contributor), which slightly improves the outlook but does not change the classification: this is a "vendor-or-fork" dependency, not a normal Composer require.

When to Consider This Package

Adopt when:

• You maintain a Laravel 5.3 application with a substantial BrowserKit-style acceptance test suite and you are upgrading the framework but not the tests, in this cycle.
• The tests are load-bearing (they guard real revenue or compliance behavior) and rewriting them is a multi-sprint effort you cannot absorb alongside the framework upgrade.
• You need a temporary bridge with a defined exit date — the macro is a migration artifact, not a permanent dependency.
• You are moving to a newer PHP runtime (8.4/8.5) alongside the framework bump; 5.9.0 explicitly supports that combination, so the shim will not become the thing that blocks the runtime upgrade.

Look elsewhere when:

• You are starting a new project. Use the framework's current testing stack (HTTP tests, Pest, Dusk where browser behavior matters). There is no reason to adopt a 5.3-era API.
• You can afford the test rewrite. A rewrite is strictly better long-term than a shim, even a maintained one.
• You need community support, security response, or long-term maintenance guarantees. Low star count and zero dependents means minimal ecosystem scrutiny — treat the code as yours the moment you install it.
• Your target Laravel version has removed or deprecated the underlying BrowserKit testing package; verify compatibility against your exact version before committing. Note that PHP 8.5 support is not the same as guaranteed Laravel-version coverage — check the release matrix.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed compatibility shim that lets us upgrade the framework — and now the PHP runtime — without simultaneously rewriting our acceptance test suite. It converts a single large, risky release into smaller, independently shippable ones, protecting the delivery date. Cost is negligible and the project is still receiving maintenance, including current PHP versions. The caveat is unchanged: adoption is minimal, so we own the code once adopted, and we should timebox it.

To engineering: The package is a macro that restores the Laravel 5.3 BrowserKit testing API inside 5.4+ test suites, so existing visit/see tests keep passing after the framework bump. Release 5.9.0 adds PHP 8.5 support via an outside contributor — a good sign that the package is not abandoned, but it is still thin, low-adoption, and trivially forkable. Assume we vendor or fork it and pin the version. It remains a bridge, not a long-term dependency: keep the follow-up ticket to migrate tests to the current stack and remove the shim, and treat the ongoing compatibility work upstream as a convenience rather than a reason to extend the exit date.