Dusk Dashboard Laravel Package

Product Decisions This Supports

• Whether to invest in the E2E feedback loop, not just the tests. Laravel Dusk already tells you pass/fail; this package answers the harder question a developer actually has at 5pm — why did it fail. Live per-test progress and timing, failure screenshots, console logs, browser exception traces, and one-click re-run of a single failed test turn "diagnosing a red Dusk build" from tribal knowledge into a visual artifact. That is a debugging-velocity proposition, and it is worth separating from the coverage conversation when you're scoping the roadmap.

• Build / buy / borrow for developer-experience tooling. The package is MIT, ~556 stars, single-purpose, zero dependents, no release since May 2020, and now archived. That pattern is a clean market signal: the capability is validated (opportunity is the strongest dimension in the assessment), the product was not sustained. The decision it should trigger is not "install or don't" but "do we internalize this pattern?" The surface is small — a Dusk route, a listener on Dusk's lifecycle events, a view for screenshots/logs — and Dusk already emits the underlying events. A thin internal equivalent is plausibly one to two sprints and removes the dependency question permanently.

• Pilot scope for a QA/DX initiative. Install is Composer plus a dedicated dev route, so time-to-signal is hours. That makes it a legitimate cheap experiment: one team, one sprint, one Dusk suite, instrument time-to-diagnose a failing E2E test before and after. The result decides whether visual test feedback is a real lever or a nice-to-have — before anyone funds an internal build.

• Tooling standard: local-first vs. CI-native. This is a live browser view of a run in progress, not a results store. It does not answer "which tests are flaky over the last 30 days" or "did this PR slow the suite down" — those are CI report and trend-analysis problems (JUnit XML, HTML reports, trace viewers). Choosing this package means choosing to optimise the local developer loop. If your actual pain is triaging failures on a PR in CI, adopting this spends the budget on the wrong half of the workflow. Making that distinction explicit is itself a product decision worth recording.

• Onboarding and QA ramp-up. Screenshots and console output on failure reduce the Laravel/browser fluency required to debug a broken Dusk test. If you hire generalists or QAs who aren't deep in Dusk internals, "can a new joiner diagnose a failing E2E test unaided in week one?" is a measurable outcome this pattern moves directly.

• Dependency policy for internal dev tooling. This package registers a route inside the application that can re-trigger browser tests and serve screenshots, console logs, and exception traces. That makes it a dev-only dependency with an environment-gating obligation, not a normal library — and screenshots routinely capture seeded data, tokens in URLs, and PII. The adoption decision is inseparable from a policy decision about how dev-only tooling is isolated from production. That policy recurs with every Telescope-style panel, debug bar, or test dashboard you add.

When to Consider This Package

Consider it when:

• Your app is on Laravel 6/7 with Dusk already in place, and the complaint is "we have E2E tests but diagnosing a failure is slow" — not "we need more tests."
• You want to validate the value of visual test feedback cheaply before committing engineering time. Hours to evaluate, not sprints.
• The audience is local development and pre-merge triage, and you can gate the Dusk route to non-production (environment check, auth, or both) and keep it out of the production dependency manifest — require-dev only.
• You are comfortable treating it as vendored or forked: pin the constraint, accept that no upstream fix will ever arrive, and name an owner for the day it breaks.
• The rest of your stack is frozen or deliberately legacy. If you're on Laravel 7 anyway, the EOL-framework objection is a constraint you've already accepted elsewhere; this adds no new class of risk.

Look elsewhere or defer when:

• You are on Laravel 8+, or have any near-term upgrade on the roadmap. The final release, 2.0.0, has a one-line changelog: "Laravel 7 support," dated May 2020. The repo is archived. This is a Composer constraint conflict, not a configuration problem you can work around, and there is no future release coming.
• Your need is CI-native reporting or historical trend analysis. This is a live dashboard over a run in progress; it is not a results store, and it will not tell you which tests are flaky over time or whether a PR made the suite slower.
• You need parallel or sharded Dusk execution across workers, or a shared dashboard for a distributed CI fleet. Neither is a supported use case for a frozen package.
• You require vendor support, security patching, or a maintained upgrade path. An archived package with no releases in five years and zero dependents has no institutional backstop; if it breaks — a Chrome/Chromedriver bump in screenshot capture, a PHP minor — you own it.
• The capability would be load-bearing for your workflow. At that point an unmaintained single-maintainer tool is an unacceptable foundation: use it as a spec, not a dependency.

Bottom line: the feature set is well-scoped and genuinely useful, and the opportunity signal is the strongest 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 short pilot or as the blueprint for an internal build, not as a long-lived dependency.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source dashboard that shows Laravel browser-test runs live — which test is running, what broke, the screenshot at the moment of failure, and the browser console. The product question it answers is whether faster failure diagnosis is worth investing in. The catch: last released in 2020, targeting Laravel 7 (out of security support), and formally archived — so we should not build a long-term workflow on it. Recommendation: approve a time-boxed pilot (one team, one sprint, one Dusk suite) to measure whether diagnosis time actually drops. If it does, fund a small internal version we control and can keep current — the underlying capability is small, and the alternative is a permanent dependency on an abandoned package. The pilot costs days; the internal build is competitive with a sprint and eliminates the maintenance question entirely. Either way, do not let it near production configuration.

For engineering: The capability is real and the surface is small — a route that serves a live view, listeners on Dusk's test-lifecycle events, and capture of screenshots, console output, and browser exceptions. Two checks before installing anything. Version eligibility: the final release supports Laravel 7 and the repo is archived, so this is a non-starter on a current Laravel version; if we pilot, it must be on an app already on Laravel 7, pinned, and understood to be unmaintained. Route exposure: it registers an in-app route that can trigger test runs and serve screenshots and logs — gate it to local/testing, assert that in a test so a future config change can't promote it, and keep it in require-dev. Confirm from source whether registration is conditional rather than unconditional. Also verify where artifacts land on disk, the retention story, and whether those captures contain regulated data. If the pilot shows value, the recommendation is to reimplement rather than depend: subscribe to Dusk's events, stream results and artifacts to a local view, and own the upgrade path.