- How do I install eliseekn/laravel-metrics in a Laravel application?
- Install it with Composer by running composer require eliseekn/laravel-metrics. The package ships no migrations or service provider configuration, so adoption is additive and reversible. Pin an exact version in composer.json and confirm the Laravel constraint in the package's composer.json before deploying.
- What PHP and Laravel versions does laravel-metrics support?
- The README lists PHP ^8.2 and Laravel ^11.x or ^12.x. The changelog indicates Laravel 12 support landed in v3.1.1, and a 4.x branch targets Laravel 13. Verify the constraint in composer.json for the exact version you pin, because README and changelog details can drift.
- How do I generate monthly trend data from an Eloquent model with laravel-metrics?
- Use the fluent API: LaravelMetrics::query(Order::query())->sum('amount')->byMonth(6)->trends(). This returns trend data for the last six months including the current month. You can also call count(), byDay(), byYear(), and metrics() for totals. The output is plain arrays suitable for charts, Blade, Livewire, Inertia, or API resources.
- Can laravel-metrics use a custom date column or a specific date range?
- Yes. Chain dateColumn('published_at') to aggregate on a column other than the default timestamp. Use between('2020-05-01', '2022-08-21') to constrain the reporting window. Combine these with byDay(), byMonth(), or byYear() to shape the trends output.
- Does laravel-metrics support MySQL, PostgreSQL, and SQLite?
- Yes, the package states support for MySQL, PostgreSQL, and SQLite. Because it generates driver-specific SQL for date grouping and truncation, test your exact database version and query shapes. PostgreSQL fixes in earlier releases show that dynamic SQL is the fragile area to validate.
- Can I use laravel-metrics with the query builder and custom tables?
- Yes. Pass a DB::table(...) query to LaravelMetrics::query() just like an Eloquent builder. Use table('users') when a join means the aggregation should target another table, and labelColumn('name') to group or label by a specific column. These identifiers are raw strings, so keep them as trusted configuration rather than user input.
- Is laravel-metrics suitable for production dashboards?
- It is a thin, stateless reporting layer, not a real-time analytics engine. It has no caching, pre-aggregation, materialized-view management, or rate limiting, so those remain application concerns. For production, wrap calls behind a project-owned service, cache expensive widgets, and test on representative data volumes.
- How should I test laravel-metrics output before replacing existing reports?
- Build one widget alongside your existing hand-written aggregation query and diff both outputs over a representative date range. Test the exact database driver, PHP version, and Laravel version you deploy, including date boundaries and timezone behavior. The package added test cases only around v3.2.0, so your own regression tests are the practical safety net.
- Does laravel-metrics cache results or pre-aggregate data?
- No. It is a stateless query-composition layer that returns arrays or collections; it does not ship caching, pre-aggregation, materialized views, or rate limiting. You must design those concerns in your application, for example by caching dashboard widgets or scheduling aggregate table updates. Avoid calling complex trends queries on every request without a cache.
- Is laravel-metrics actively maintained, and what are the alternatives?
- It is a single-maintainer package with a small dependent ecosystem, so bus factor and version-pinning drift are risks to manage. The changelog shows ongoing fixes and newer branches, but you should pin and test explicitly. Alternatives include hand-written GROUP BY queries, a project-owned reporting service, or dedicated analytics and BI tooling.