- What is Bitter and what does it do?
- Bitter is a small, framework-agnostic PHP analytics library. It models a metric as a named aggregation such as sum, count, or average over a time period, resolved through a data source and persisted through a repository. It is not a full monitoring platform, and despite some descriptions of it as a feature flag package, its code is built around metric aggregation.
- Is Bitter a Laravel package?
- No. Bitter ships no Laravel service provider, facade, config stub, migration, or queue integration. It is a plain PHP domain library, so any Laravel wiring is code you write and maintain. That makes it a component rather than an install-and-go package.
- How do I install Bitter in a Laravel project?
- The mechanical step is composer require free-agent/bitter, followed by a thin wrapper class bound into the container. Before that, run a compatibility spike against your PHP and Laravel versions because the project is archived and targets PHP 5.6 and 7.x. Do not use --ignore-platform-reqs as a production workaround.
- Does Bitter support PHP 8.2, PHP 8.3, and current Laravel versions?
- There is no official support statement for modern PHP or Laravel. The project is archived and sits in the PHP 5.6 and 7.x era, so its Composer constraints may exclude current runtimes. Check the tag's platform requirements first; if they block you, plan a fork with PHP 8 compatibility fixes rather than overriding constraints.
- Is Bitter still maintained?
- No. The repository is archived, which means no security patches, no PHP 8 compatibility work, and no upstream response to CVEs or breaking transitive dependency changes. The MIT license does allow a hard fork, and that is the realistic mitigation. Treat it as a vendored internal component, not a live upstream dependency.
- What storage backend does Bitter use?
- Bitter does not ship a documented storage backend of record. It abstracts persistence behind a repository, and there is no maintained Eloquent, Redis, or InfluxDB adapter. You will implement the repository against your own schema and own the persistence design, tests, and documentation.
- How do I connect Bitter to Eloquent or my database?
- Implement Bitter's repository interface with an Eloquent-backed class and bind it in a Laravel service provider. Map your metric aggregations to either raw event tables or pre-aggregated rollups, depending on read volume. The choice matters: on-demand aggregation over raw tables may not survive contact with production data volume.
- What are good alternatives to Bitter in Laravel?
- Laravel Pulse, Prometheus, StatsD-style tooling, and hand-rolled GROUP BY queries are the usual alternatives. Bitter fits narrow internal metric computation such as admin dashboards and simple KPI panels, not application performance monitoring or user-facing reporting at scale. If you need a maintained platform capability, choose one of those instead.
- What are the production risks of using Bitter?
- The dominant risk is lifecycle, not code quality: archived status means no patches and no compatibility work. Adoption signals are thin at 128 stars and zero dependents, so aggregation math and period boundary handling are effectively untested in the wild. Timezone and period boundary behavior should be covered by your own tests before relying on results.
- Should I fork Bitter or depend on the upstream tag?
- For production, fork or vendor it under an internal path, pin the version, add PHP 8 fixes and a test suite, and publish to a private Composer registry. A thin in-house wrapper over the upstream tag is only defensible if a compatibility spike shows it installs cleanly and the aggregation semantics match your reporting definitions. Inspect the codebase size to estimate whether fork-and-own work is days or weeks.