Cache Stats Bundle Laravel Package

Technical Evaluation

Architecture fit. Nothing in v0.7.2 changes the core finding: the artifact is a Symfony Bundle (pablok/cache-stats-bundle), not a Laravel package. A Bundle is a DI-container extension plus a Bundle class plus optional routing/console wiring — none of which Laravel's service container consumes. The substance remains thin and framework-agnostic: a presentation layer over three native PHP introspection APIs — opcache_get_status(), apcu_cache_info()/apcu_sma_info(), and realpath_cache_get()/realpath_cache_size(). Those functions are available to any PHP process. So the question is still "is the normalization logic worth lifting into a Laravel provider?" — and v0.7.2 is evidence for that framing rather than against it: the release's only change is configuration plumbing ("Use PHP config", PR #38), i.e., churn in the Symfony packaging layer, not in the diagnostic logic. The concept is sound; the delivery vehicle is not, and the newest release is another coat of paint on the vehicle.

Integration feasibility. Unchanged: low-to-moderate effort, high determinism. No database, no queue, no external service. Port service definitions into a ServiceProvider, lift the stats-normalization classes, replace Symfony routing/annotations with Laravel routes, re-implement console commands as Artisan commands. Estimated 2–5 engineer-days. The vendor package should be treated as reference source, not a dependency — composer require in a Laravel app pulls Symfony bundle machinery that will never boot. One narrow delta from v0.7.2: the fork should discard the bundle's config layer entirely rather than translate it, since upstream just demonstrated that layer is still moving (YAML → PHP config) while the introspection core is static.

Technical risk.

• Adoption signal is still weak. 10 stars, 0 dependents, opportunity score 22.79 against a quality score of 8.57. Competently built, no market pull, no third-party validation, no battle-testing.
• Bus factor of one — marginally improved. Single-maintainer namespace (PabloKowalczyk), but v0.7.2 ships a GitHub Sponsors call-to-action and continued incremental releases. That is a weak but real continuity signal: there is some incentive alignment to keep shipping. It is not a support commitment, and it does not change the fork-and-own recommendation. MIT license remains the mitigation.
• Release hygiene anomaly persists. The previously stated last release (2026-03-22) is still out of step with the calendar. v0.7.2 is a fresh tag on top of that lineage; verify tags/checksums before pinning rather than trusting registry metadata.
• Exposure risk remains dominant. These bundles typically register an HTTP endpoint dumping opcache config, script counts, hit rates, and memory layout — reconnaissance-grade information. Any port must be behind auth, IP allowlisting, or CLI-only from day one.
• No security review trail. Zero dependents means no downstream CVE surface discovered — but also no downstream scrutiny.
• Config-format churn (new, low severity). "Use PHP config" implies a supported-configuration change. For a Symfony consumer that could mean migrating YAML bundle config; for us it is a non-event, because we take the normalization classes and write our own Laravel config. Risk is confined to how much Symfony scaffolding we accidentally carry over.

Key questions.

1. What decision does this telemetry drive — tuning opcache.memory_consumption/max_accelerated_files, right-sizing realpath_cache_size, APCu eviction tuning? If nobody owns those knobs, the dashboards are decoration.
2. Are we FPM only, or does the fleet run Octane/Swoole, where long-lived workers make per-process realpath-cache and APCu stats structurally different?
3. Do we already have APM (Datadog, New Relic, OpenTelemetry, Prometheus)? Most agents already ship OPCache metrics; if so this is duplicate signal.
4. Is the consumer a human on a dashboard or an automated alert? The package targets the former.
5. Does v0.7.2 deprecate YAML bundle config, or merely add PHP config alongside it? (Matters only if any internal team runs the Symfony bundle directly today — confirm before anyone pins or upgrades.)
6. Did PR #38 touch public service IDs or config keys, or only the config loader? Determines whether the fork should re-sync from v0.7.2 or stay on v0.7.1 as its upstream base.
7. Who forks and owns the internal version when upstream goes quiet — platform team or app team?

Integration Approach

Stack fit. Unchanged. PHP 8.x with OPcache enabled is the baseline; APCu is optional and only meaningful under FPM (a CLI process has its own empty segment — classic source of misleading "0% hit rate" graphs). The framework-agnostic core makes the port a packaging exercise. Natural home: a small internal package (acme/cache-diagnostics) with a service provider, published config, one Artisan command, one guarded route.

Migration path. Three routes, ascending cost — all unchanged by v0.7.2:

1. Vendor-and-adapt (recommended). Fork under the org namespace, strip Symfony bundle wiring including the config layer that just changed, keep normalization logic, add a CacheStatsServiceProvider, tag as internal. Preserves upstream diffability minus dead scaffolding.
2. Clean-room reimplementation. ~150 lines calling the three native functions. Fastest to own; loses upstream edge-case handling (e.g., opcache_get_status(false) summary vs true script-level payloads).
3. Run Symfony alongside Laravel. Technically possible via a bridge; categorically not worth it for read-only telemetry. Reject.

Compatibility. Verify the port against every runtime in the matrix: FPM, CLI, queue workers, Octane/Swoole. Under Octane, realpath cache and APCu persist and grow across requests, so "cache full" heuristics tuned for per-request FPM lifecycles produce false positives. Confirm behaviour when opcache.restrict_api is set or apcu.enabled=0 — must degrade to explicit "unavailable," never silent zeros. Note v0.7.2's config change is inert here: our config is Laravel's, not the bundle's, so no YAML-to-PHP migration work is inherited.

Sequencing.

1. Spike (3–5 days). Stand up route 1 in staging; confirm the three APIs return sane values across FPM/CLI/worker contexts; measure overhead of opcache_get_status(true) (script-level is materially more expensive than summary).
2. Harden. Auth/allowlist, enable flag defaulting to false, config-driven exposure, redaction of absolute paths if reachable beyond localhost.
3. Internalize. Fork, rename, publish to internal Composer registry, add contract tests around the native-function wrappers. Pick the upstream base commit deliberately (v0.7.1 vs v0.7.2) after a five-minute diff of PR #38.
4. Ship read-only. Land the Artisan command first (cache:stats) for on-box debugging; defer the HTTP endpoint until a genuine dashboard consumer exists.
5. Decide on aggregation. Only after single-node signal proves useful — a collector shipping node-local snapshots to Prometheus/OTel is a separate, larger build.

What changed for integration: nothing material. No breaking API change to the introspection logic, no new features, no new dependencies. The release is a config-plumbing patch; the integration plan and its cost estimate stand.

Operational Impact

Maintenance. Low code volume; unowned upstream. Zero dependents means no community to absorb maintenance. Budget for the internal fork being the permanent home. The PHP extension APIs it wraps are decades-old and stable, so PHP-upgrade churn is small — the churn lives in the framework packaging (exactly what v0.7.2 modified), which becomes ours to control once forked. Practical cost: a few hours per year of dependency review plus the initial fork. The v0.7.2 sponsor link is a mild positive for upstream longevity but should not be relied on in a support plan.

Support. No vendor, no SLA, no issue-response expectation from a 10-star single-maintainer project. Support comes from the platform team. Mitigate by keeping the surface deliberately narrow: one command, one optional route, one config file. Do not let it grow into a general "PHP internals dashboard" — that is how a 300-line utility becomes an unowned product. If any internal app runs the Symfony bundle directly today, that team owns a small config migration as a result of v0.7.2; scope it before it surfaces as a surprise.

Scaling. Inherently node-local, single-process telemetry. It cannot observe a fleet: each FPM pool and each worker has its own realpath cache and APCu segment. Consequences:

• At N nodes you get N disjoint snapshots with no correlation — you need an external collector and a per-node label scheme, or the data is uninterpretable.
• Under Octane, bound the sample frequency; the calls are cheap but not free, and opcache_get_status(true) on a large codebase returns thousands of script entries, inflating payload and serialization cost.
• Cardinality is bounded (three metric families), so the scaling story is benign provided the full script-level dump never reaches a metrics pipeline.

Failure modes.

• Information disclosure — unauthenticated stats endpoint leaking absolute paths, extension versions, opcache config. Highest severity, highest likelihood.
• Silent zeros — APCu or OPcache disabled in a SAPI yields empty results rendered as "0% hit rate," driving false incidents and eroding trust.
• Threshold drift — hard-coded "cache full" heuristics wrong under Octane and under varied opcache.validate_timestamps settings.
• Payload blowup — script-level dumps saturating log pipelines or response buffers.
• Orphaned fork — upstream archives, internal fork diverges, nobody remembers why a config key exists.
• Metadata surprise — the anomalous release date plus a config-layer change in a patch release argue for diffing PR #38 and verifying tags before pinning.
• Config-migration surprise — small, contained: only bites teams consuming the Symfony bundle directly; irrelevant to the recommended fork path.

Ramp-up. Very shallow. Any mid-level PHP engineer can read the whole package in an afternoon; the real cost is domain knowledge (what realpath cache and APCu do, why hit rate matters), not code. ~1 day onboarding for the port owner, ~15 minutes for an on-call engineer to learn the Artisan command. v0.7.2 adds no new ramp-up.

TPM verdict. Unchanged. Strong concept, weak distribution — an 8.57 quality score against a 22.79 opportunity score is the whole story. v0.7.2 is a patch-level config-plumbing release with a sponsor note: it signals a maintainer still shipping (mildly reassuring on continuity) and it re-confirms that the only moving parts are Symfony packaging, not the diagnostics. Treat the package as reference implementation to be internalized, not a dependency — 2–5 engineer-days buys permanent ownership of a genuinely useful diagnostic surface, with the single hard gate that any HTTP exposure ships authenticated and default-off. No re-evaluation of priority is warranted; if the team already runs an APM agent reporting OPCache metrics, close this out as duplicate signal and spend the days elsewhere.