Dashboard Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing to correct in the intake record: spipu/dashboard-bundle is a Symfony bundle, not a Laravel package (the repo name is symfony-bundle-dashboard). It is the Symfony integration layer for the vendor's standalone spipu/dashboard rendering library, wiring dashboard definitions into Symfony's DI container, configuration tree, and Twig/asset pipeline. That makes it a good fit for a Symfony 6/7 application with an existing bundle-based architecture and a poor fit for Laravel, where the correct move would be to consume the underlying library directly and hand-roll the service provider and view glue.

Integration feasibility. Mechanically straightforward: Composer install, register the bundle in config/bundles.php, import the bundle's config, publish/point at assets, define dashboards as services. The real feasibility question is not "can we install it" but "what does it save us over the core library" — the bundle is thin glue, so the value is DI ergonomics and convention, not functionality we couldn't replicate in a day or two of adapter code.

Technical risk. High, and concentrated in project health rather than code:

• 1 star, 0 dependents. No ecosystem validation. Nothing to indicate anyone else has run this in production, and no downstream projects to surface breakage before we do.
• Single-maintainer / bus factor of one, with an unclear support commitment.
• Release metadata anomaly (last release dated 2026-09-30). Treat version/date signals as unreliable until verified against Packagist and the tag history — this is exactly the kind of thing that hides an abandoned repo behind a plausible-looking timestamp.
• Composite score 19/100 is a health signal, not a code-quality verdict: it is telling us adoption, activity, and community depth are all near zero. The 38.68 opportunity score suggests real whitespace in the "dashboard composition for Symfony" niche, but whitespace plus one star usually means the market didn't want it, not that it was missed.
• Security/BC exposure is low-surface but unpatched. A dashboard renderer is not deep in the auth path, but a Symfony major bump or a Twig CVE will not be fixed for us.

Key questions for the maintainer spike. Which Symfony and PHP versions are actually supported and tested? Does it delegate all meaningful logic to spipu/dashboard, or does it fork behavior? Is there a CI matrix and test suite, and what is its coverage? What is the declared BC policy across Symfony majors? Who else is using it? What are the rendering targets (HTML/PDF/image) and does the PDF path pull spipu/html2pdf, which would widen our dependency surface?

Integration Approach

Stack fit. Clean if we are on Symfony 6.4/7.x with Twig and a standard bundle config; if we are on Laravel, stop here and evaluate the underlying spipu/dashboard library as a standalone dependency instead. Do not adopt a Symfony bundle into a Laravel app via a shim — the shim becomes the maintenance liability, not the package.

Migration path. Do not build dashboards directly against bundle service IDs or its config schema. Define an internal DashboardProvider interface and a small DTO layer in our own namespace, implement it with the bundle behind it, and keep exactly one adapter file that imports vendor classes. If the package is abandoned or breaks on a Symfony upgrade, we swap the adapter for a hand-written implementation against the core library and delete one file. That containment is the whole reason a 1-star dependency can be acceptable at all.

Compatibility. Pin an exact version in composer.json (no caret range on a package with no downstream users to shake out breakage), commit the lockfile, and record the supported PHP/Symfony matrix in an ADR. Verify composer why-not against our current Symfony version before committing to a spike.

Sequencing.

1. Timeboxed spike (1–2 days): install in a branch, build two representative dashboards, confirm rendering, config, and asset flow end to end.
2. Health check: Packagist download stats, tag history, open/closed issue ratio, whether spipu/dashboard core is the actively maintained piece.
3. Decide buy vs. build: if the spike shows the bundle is ~200 lines of glue, build the adapter directly against the core library and skip the dependency entirely. This is the likely outcome.
4. If adopted: wrapper interface, pinned version, Renovate/Dependabot with a manual-approval policy, fork-and-vendor contingency documented.
5. Never make it a hard dependency of a customer-facing SLA path without a named internal owner.

Operational Impact

Maintenance. Assume we own it. With one maintainer, zero dependents, and a 19/100 health score, the realistic operating model is "vendored fork we occasionally rebase," not "upstream we consume." Budget a small but permanent tax: Symfony upgrade cycles will require us to patch the bundle ourselves, and that work lands on whoever owns the dashboard surface, not on the vendor.

Support. No community, no Stack Overflow corpus, no third-party tutorials. Every question routes to one person's GitHub issues tab or to reading the source. Ramp-up cost is therefore not the bundle's small API, but the adjacent spipu/dashboard core concepts — expect 1–3 days for a competent Symfony developer, longer if the PDF rendering path is involved and html2pdf drags in its own quirks.

Scaling. Dashboards are read-heavy and render-bound. The bundle does not solve caching for us; we will need to cache rendered output or memoize data providers ourselves. If dashboards become a frequently-hit page, the render cost sits in the request path, and the package gives us no lever for that — plan an output cache and measure before and after.

Failure modes, ranked.

1. Silent abandonment — no releases, then a Symfony major makes it uninstallable. Mitigation: wrapper interface, pinned version, fork contingency.
2. Symfony major upgrade breakage — bundle services or config schema drift. Mitigation: adapter isolation, upgrade rehearsal in CI.
3. Service ID or config-key collisions with our own container. Mitigation: verify in spike, namespace our config.
4. Dependency widening via the PDF/HTML rendering chain, pulling in packages with their own CVE exposure.
5. Metadata-driven false confidence — the anomalous 2026 release date means automated "is it maintained?" checks will report green on a dead project. Mitigation: human review on every bump, not automated merge.

Recommendation. Treat this as a build, don't buy candidate: the whitespace is real but the package is not validated, and what it provides is thin glue over a library we can integrate directly. Approve a two-day spike only, gated on the outcome being a decision between "adopt behind an adapter" and "reimplement the glue in-house" — with the default expectation being the latter. If a stakeholder wants dashboards fast, the honest framing is that this dependency trades a few days of integration work for an indefinite, low-visibility maintenance obligation.