Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
MetricPanel for Laravel adds a configurable metrics dashboard to your application. Define panels and cards in code to display stats, trends, and custom KPIs in an admin area.
View on GitHub
Deep Wiki
Context7
Getting Started
Treat v0.1.0 as an early preview. Pin the exact version in Composer until the README and changelog confirm a stable API and SemVer policy.
Start with the README’s installation and delivery-guarantee sections, then inspect the package service provider, config file, and allowlist implementation. Those are the first places to confirm what is actually enforced.
First use case: register one non-critical MetricPanel export from the canonical source in local/staging, run it manually, confirm unlisted sources are rejected, then move it behind a scheduled command or authenticated admin route.
Implementation Patterns
Keep exported panels/sources in config or environment-specific config, not hard-coded in commands or controllers.
Resolve the exporter through Laravel’s container rather than instantiating it directly. This keeps tests and future package changes easier to manage.
Wrap exports in a queued job or scheduled command. If delivery guarantees are at-least-once, make downstream handling idempotent and log export identifiers.
Add feature tests around the allowlist: one allowlisted source succeeds, one non-allowlisted source fails closed.
Expose any manual export UI only behind existing auth/admin middleware. Do not expose raw export endpoints publicly.
Use the canonical MetricPanel source as the integration boundary. Avoid adding ad-hoc exporters until the package documents an extension contract.
Gotchas and Tips
The release note is sparse. Verify the README’s “delivery guarantees” before relying on retries, ordering, or exactly-once behavior.
Treat the allowlist as a security boundary. Confirm matching is normalized and fails closed; audit config changes like production credentials.
v0.1.0 APIs are likely to move. Pin the version, read changelogs before upgrades, and avoid spreading package-specific calls across the codebase.
When debugging, clear config cache, confirm the service provider is discovered/registered, and log the normalized source name being checked against the allowlist.
Prefer package-provided extension points over bypassing the canonical source or allowlist. If you must extend, keep the bypass impossible in production configuration.
Weaver
How can I help you explore Laravel packages today?