Dashboard Module Laravel Package

Technical Evaluation

Architecture fit

anomaly/dashboard-module is not a conventional Laravel package — it is an addon for the Streams Platform (the framework underpinning PyroCMS 3.x), authored by the same vendor. It assumes the addon architecture (service providers registered through the Streams addon registry, addons/{vendor}/{namespace}-module directory conventions, control-panel route/asset bindings) and composes with anomaly/widgets-module to render configurable dashboard widgets inside the admin control panel. If our target application is a standard Laravel app, or uses a different CMS/admin layer (Filament, Nova, Orchid, custom Vue admin), this package has effectively zero architectural fit: it cannot be dropped in without pulling the entire Streams Platform as a dependency.

Integration feasibility

Viable only in one scenario: we are already building on, or are willing to adopt, Streams Platform / PyroCMS 3.x. In that case integration is standard-composer (composer require anomaly/dashboard-module), enable the addon, run its migrations, and assign control-panel permissions to roles. The dashboard surface itself is user-configurable via the widgets system, which is genuinely useful out of the box. Any other scenario means adopting a second framework on top of Laravel — a disproportionate cost for a feature that is essentially a widget grid.

Technical risk

High. The adoption signals are weak across the board: 3 stars, 0 dependents, an overall score of 0.375, and an opportunity score of ~25.5 — all consistent with a package that exists primarily as an internal component of the PyroCMS distribution rather than as an independently maintained library. The ecosystem era is Laravel 5.x / PHP 7.x with tight version constraints on anomaly/streams-platform; Composer resolution against Laravel 9/10/11 and PHP 8.2+ is likely to fail or require forking and constraint surgery. There is no visible community, no third-party dependents to validate it in the wild, and support will come from us, not upstream.

Key questions

• Are we committed to Streams Platform for the product, or is this a shortcut to a dashboard we should build ourselves?
• What Streams Platform version is targeted, and does that version support our PHP/Laravel baseline?
• Who owns the fork if upstream is inactive — do we have the appetite to vendor and patch it?
• Is the required functionality (a widget-based admin dashboard) worth the platform-level lock-in versus ~1–2 weeks of bespoke build in our existing stack?
• What is the exit cost if Streams Platform is abandoned entirely mid-product?

Integration Approach

Stack fit

Assume Streams Platform is a hard prerequisite. That dictates PHP 7.x-era constraints (realistically PHP 7.2–7.4, Laravel 5.4–5.8) unless we invest in upgrading the platform itself. If our product is a greenfield Laravel app on PHP 8.2+ / Laravel 11, do not integrate — mirror the concept (a permissioned dashboard with pluggable widgets) in our own admin layer instead.

Migration path

For an existing Streams/PyroCMS installation: require the package with a pinned version, enable the addon, run php artisan addon:install anomaly/dashboard-module, publish/verify its assets, and seed default dashboard pages for each role. Existing admin routes are unaffected; the module adds a CP section rather than altering core routing. There is no meaningful migration path into this package from another dashboard system — the value is the prebuilt Streams-native widget grid, not data portability.

Compatibility

Pin every Streams-ecosystem dependency to exact versions in composer.lock and treat upgrades as deliberate projects, not routine maintenance. Verify anomaly/widgets-module is present at a compatible version — the dashboard is largely inert without it. Audit the addon's service provider against our Streams version before committing; internal addon APIs (addon registry, CP asset collection) are the most likely break points.

Sequencing

1. Confirm platform decision (Streams vs. build-our-own) — gate for everything else.
2. Stand up a Streams Platform baseline with PHP/Laravel versions pinned and CI-enforced.
3. Install widgets module, then dashboard module; validate widget rendering and permissions end-to-end.
4. Vendor-fork the package into our VCS at first sign of needed patches.
5. Only then expose the dashboard to end users.

Operational Impact

Maintenance

Effectively self-maintained. With 3 stars, 0 dependents, and no visible upstream activity, we should plan on owning the code: fork it, vendor it, or (preferably) isolate it so it can be replaced. Budget ongoing time for PHP/Laravel security patching of the platform layer, which is the larger cost than the module itself.

Support

No community, no issue backlog to lean on, no third-party documentation beyond the Streams Platform docs. Support is internal knowledge — a single point of failure if one engineer holds it. Document the addon's behaviour and the widget contract as part of onboarding.

Scaling

The module is thin: it renders dashboard pages and widget containers. Scaling concerns live in the widgets themselves (queries, caching) and in the Streams Platform's admin stack. For a low-to-moderate number of admin users this is a non-issue; for high admin concurrency or widget-heavy dashboards, profile widget queries individually rather than the module.

Failure modes

• Composer resolution failure on any platform or PHP upgrade — the most likely and most disruptive event.
• Widget module missing or mismatched, producing a blank or broken CP dashboard.
• Permission/role misconfiguration exposing dashboard panels to the wrong roles.
• Addon asset publishing drift after deploys, causing stale JS/CSS in the control panel.
• Silent abandonment upstream combined with PHP EOL, accumulating unpatched security exposure.

Ramp-up

Non-trivial for teams without Streams experience: developers must learn addons, streams, widgets, and the control-panel conventions before they can safely modify the dashboard — realistically 1–2 weeks of ramp-up, more than the integration itself. Mitigate by treating the dashboard as configuration-first and resisting customisation until the team is fluent. Given the weak adoption signals, the honest recommendation is to build a lightweight equivalent in our own stack unless Streams Platform is already a committed platform decision.