Dusk Dashboard Laravel Package

Technical Evaluation

Architecture fit. beyondcode/dusk-dashboard is a Composer-distributed Laravel package whose role is to observe another tool — Laravel Dusk — while it runs. It integrates via a service provider that publishes config and registers a dedicated dashboard route, exposing a live browser view of test execution: per-test pass/fail, timing, assertions, failure screenshots, console logs, browser exceptions, and one-click re-run of failed tests. Architecturally this is an idiomatic, low-ceremony Laravel dev-tooling shape, and it is strictly a development/triage surface — it adds observability over the browser suite, not a business capability. The fit question is therefore narrow: does the consuming app already run Dusk, and can the package's route be environment-gated so it never renders in production. Verify from source that route registration is conditional (env/config check) rather than unconditional; an always-on route that can re-trigger browser test runs and serve captured screenshots is an exposure, not a feature.

Integration feasibility. High for the right target, blocked for the wrong one. The only release artifact we have is 2.0.0 — "Laravel 7 support" — dated 2020-05-29, with the repository now archived. Reading through SemVer, the package's support ceiling tracks Laravel 7, implying Symfony 5 and PHP 7.2.5+. A Laravel 8+ application will hit a Composer constraint conflict, not a code error, so this is a stack-selection gate, not an integration-effort estimate. Practically: viable for a legacy Laravel 6/7 app with an existing Dusk suite; not viable on a modern Laravel release, and not worth downgrading anything to reach.

Technical risk. Four risks, in priority order:

1. Abandonment is realized, not forecast. Archived repo, no release in ~5 years, 0 dependents. There is no upstream patch path for anything — security, PHP minor bumps, or a Chrome/Chromedriver version break in screenshot capture.
2. The capability is partially commoditized. Dusk already writes failure screenshots and console output to disk, and CI providers already archive artifacts. The package's differentiated value is the live dashboard, per-test timing, and one-click failed-test re-run — a developer-experience delta, and DX deltas decay fast against a frozen dependency.
3. Exposure surface. A route that executes tests on demand and serves screenshots, browser exceptions, and console logs is by default an unauthenticated window into your app's behavior. Screenshots routinely capture seeded data, tokens in URLs, and PII. This must be gated to local/testing, reviewed once, and asserted in a test so a future config change cannot promote it.
4. Evidence risk. The 2.0.0 note is one line with no breaking-change detail, so the 1.x→2.0 boundary is undocumented. Anyone inheriting a 1.x pin should assume a config republish and behavioral drift until proven otherwise.

Key questions.

• Does the consuming app actually run Dusk today, and is the suite load-bearing or aspirational?
• Is route registration environment-gated by default, and can we assert that in CI?
• What is the real Laravel/PHP ceiling — does composer.json hard-pin Laravel 7, and is there a trusted community fork on Laravel 8+?
• Where do screenshots and logs land on disk, what is the retention story, and do they contain regulated data?
• How does the live view get updates — polling, SSE, websockets, filesystem watch? That determines whether it needs a worker, a port, or nothing.
• Does the failed-test re-run endpoint shell out, and with what arguments? Any command-injection or arbitrary-test-selection concern?
• What is the measured cost of a flaky E2E failure today (engineer-hours per week) — i.e., what is the DX problem actually worth solving?

Integration Approach

Stack fit. Target: a Laravel 6/7 application, PHP 7.2–7.x, an existing Dusk suite, and a CI pipeline that already produces test artifacts. The package belongs in require-dev and only ever in require-dev. It does not fit a Laravel 8+ codebase, and no configuration makes it fit — the conflict is at dependency resolution and cannot be worked around without a fork.

Migration path. There is no upgrade-style migration worth planning here; treat this as greenfield dev-tool adoption or a decision to leave it out.

• Adopting fresh on Laravel 6/7: add as a dev dependency pinned to ^2.0, publish config, confirm the route is gated to non-production, run the existing Dusk suite end-to-end, and verify screenshots, console logs, and re-run all function.
• Already on 1.x: do not chase 2.0.0 without the diff. A major bump with a one-line note buys nothing if 1.x works on your framework version, and risks config drift.
• On Laravel 8+ (the common case): the correct path is not this package. Evaluate (a) Dusk's native failure screenshots plus CI artifact upload, (b) a maintained E2E stack — Cypress/Playwright — if the goal is genuinely better failure diagnosis, or (c) vendoring this package under MIT if the live-dashboard experience is uniquely valuable and you accept ownership.

Compatibility. Build the matrix explicitly before committing, sourced from composer.json and CI status rather than the changelog: Laravel version × PHP version × Dusk version × package version. Add two rows the changelog will not tell you about — the Chrome/Chromedriver version the screenshot capture depends on, and whether the dashboard behaves correctly under a parallelized Dusk run. Both are predictable breakage points for a frozen package.

Sequencing.

1. Confirm the app's Laravel, PHP, and Dusk versions; if Laravel ≥ 8, stop and route to the alternatives above.
2. Read the service provider and routes file directly. Confirm environment gating, storage path, and how the live view is fed.
3. Gate the route (env check and/or auth), and add a regression test asserting the route 404s outside local/testing.
4. Install as a dev dependency only; verify it is absent from the production dependency manifest and does not load in production config.
5. Run one real Dusk suite and capture baseline diagnosis time for a failing test (before/after instrument).
6. Time-box the pilot (one team, one sprint) with an explicit exit criterion; decide adopt-as-vendored vs. reimplement vs. drop.

Operational Impact

Maintenance. Effectively 100% internal from day one. The upstream is archived with no releases in five years; every future break — a PHP minor bump, a Chrome/driver change, a framework patch — is ours to fix or accept. Because the surface is small (a route, listeners on Dusk's test-lifecycle events, a view), a fork or thin reimplementation is a credible one-to-two-sprint alternative that removes the dependency entirely and restores an upgrade path.

Support. No vendor support, no security patching, no documentation beyond a description and a one-line changelog. Internal ownership must be assigned by name for the day it breaks; without that, it becomes the classic unmaintained dev dependency that silently rots until a new hire cannot get it running.

Scaling. The dashboard is a single-run, local-loop artifact, not a results store. It does not answer "which tests are flaky over 30 days" or "did this PR slow the suite down," and it is not designed for parallel or sharded Dusk execution across a CI fleet or a shared multi-developer dashboard. If the organizational need is CI-native reporting or historical trend analysis, this is the wrong half of the workflow — that requires JUnit/HTML reporting or a different class of tool.

Failure modes. Enumerate them for the runbook: Composer resolution failure on framework upgrade (guaranteed on Laravel 8+); screenshot capture breaking on a Chromedriver bump with no upstream fix; route accidentally exposed in a non-local environment, leaking screenshots, console logs, and exception traces that may contain seeded data or PII; disk growth from accumulated artifacts with no built-in retention policy; re-run endpoint shelling out to the test runner with unclear argument handling (command-injection and arbitrary-test-selection review required); and behavioral drift at the undocumented 1.x→2.0 boundary.

Ramp-up. Low for developers already writing Dusk tests — install is Composer plus a route, time-to-signal measured in hours, which is what makes the pilot cheap. The real ramp-up benefit is inverse: screenshots and console logs on failure lower the Laravel/browser fluency needed to diagnose a broken E2E test, so "can a new joiner debug a failing E2E test unaided in week one?" is a measurable outcome this pattern moves directly. The ramp-up cost is on the maintainer side, not the user side: whoever owns it must understand the service provider, the event listeners, and the artifact storage well enough to patch them.

Bottom line. The feature set is well-scoped and genuinely useful, and opportunity is the strongest dimension in the assessment — but the package is archived and pinned to an EOL framework. Read it as a validated prototype of a capability: appropriate for a time-boxed pilot on a Laravel 7 app or as the blueprint for an internal build, and not as a long-lived dependency.