- Can I use pablok/cache-stats-bundle in a Laravel application?
- Not directly. It is a Symfony bundle built around a DI container extension and a Bundle class, which Laravel's service container never boots, so a composer require pulls in machinery that will never run in a Laravel app. The practical approach is to treat the repository as reference source and port the stats-normalization classes into your own ServiceProvider.
- What cache metrics does this bundle actually track?
- It reports hits, misses, writes, and deletes across the cache pools you configure, plus eviction-style signals surfaced in the Symfony Profiler panel. Under the hood, the technical evaluation describes it as a presentation layer over opcache_get_status(), apcu_cache_info()/apcu_sma_info(), and realpath_cache_get()/realpath_cache_size(). That means the numbers are per-PHP-process telemetry rather than a global view of a cache cluster.
- How hard is it to port this Symfony bundle to Laravel?
- Low to moderate, estimated at two to five engineer-days. There is no database, queue, or external service to wire up, so the work is mostly mechanical: move service definitions into a ServiceProvider, lift the normalization classes, replace Symfony routing and annotations with Laravel routes, and rewrite console commands as Artisan commands. Determinism is high because the underlying introspection functions are plain PHP.
- Which cache pools does it collect statistics from?
- Only the pools you register explicitly in the bundle configuration, since it integrates with Symfony Cache pool definitions and framework config. The setup is deliberately lightweight, so expect to declare each pool rather than getting automatic coverage of everything in the container. A pool that is not configured will not appear in the Profiler output.
- Is there a Laravel-native alternative for cache statistics?
- Yes, several. Laravel Telescope and Laravel Debugbar show cache hits, misses, and keys during development with no porting work, and APM agents such as Datadog, New Relic, OpenTelemetry, or Prometheus usually ship OPCache and APCu metrics already. Check whether your existing observability stack emits the same signal before porting anything, because duplicated telemetry is the most common reason packages like this get abandoned.
- Is it safe to expose cache stats in production?
- Be careful. Bundles like this typically register an HTTP endpoint that dumps OPcache configuration, script counts, hit rates, and memory layout, which is reconnaissance-grade information for an attacker. If you port it, put the route behind authentication, IP allowlisting, or CLI-only access from day one, and note that the upstream package has no public security review trail.
- Does the bundle work with Laravel Octane or Swoole?
- Not as shipped, and the semantics change even after a port. OPcache, APCu, and the realpath cache are per-process, so under long-lived workers like Octane or Swoole the figures describe a worker that persists across requests instead of a fresh FPM process. Realpath-cache and APCu numbers are therefore structurally different from what you would see under php-fpm, and dashboards need to be read differently.
- Which PHP and Symfony versions does v0.7.2 support?
- The package context here does not list explicit version constraints, so check composer.json on the GitHub repository before pinning anything. The only notable change in v0.7.2 is a move to PHP-based bundle configuration (PR #38), which implies a supported-configuration change for Symfony consumers. Verify tags and checksums against the repository rather than trusting registry metadata, because the listed release dates are inconsistent.
- Is pablok/cache-stats-bundle actively maintained?
- Marginally. There is a single maintainer, roughly 10 stars, and zero dependents, which means no third-party validation and no downstream scrutiny. Recent incremental releases and a GitHub Sponsors call-to-action are a weak but real continuity signal, not a support commitment. The MIT license is your mitigation: fork the code and own it instead of depending on upstream.
- What license is it under and can I fork it?
- MIT, so forking and commercial use are permitted with attribution. The recommended pattern is exactly that: keep the upstream repository as reference source, copy the normalization logic into a Laravel package you control, and discard the Symfony bundle config layer entirely rather than translating it. Upstream just moved from YAML to PHP config, which shows that layer is still churning while the introspection core is static.