Cache Info Bundle Laravel Package

Technical Evaluation

Verdict up front: this is not a dependency a TPM should approve for a Laravel product. mapado/cache-info-bundle is a Symfony FrameworkBundle extension, archived, with 1 star and 0 dependents. It has no ServiceProvider, no Laravel auto-discovery block, and no maintainer. The leverage a TPM extracts from it is decision support — a cheap reference for scoping an in-house replacement — not an integration into our stack.

Architecture fit — none for Laravel. The package hooks Symfony's HttpKernel / HttpCache / Store and registers through bundles.php. Laravel has no bundle registry and does not run the Symfony reverse proxy by default, so even a "successful" install would have no cache store to inspect. There is nothing for it to report on in our runtime.

Integration feasibility — near zero as-is; feasible only as a concept port. A Composer install will likely collide with the Symfony component versions Laravel 10/11 already pins. The reusable asset is the idea (surface HIT/MISS, cache key, TTL, Age, Cache-Control in a dev-only diagnostic) plus a small amount of header-formatting logic. The integration code is not reusable.

Technical risk — high. Archived upstream means zero security patching, zero PHP 8.2+/Laravel 10+ compatibility work, and no incident escalation path. Pulling it in creates a permanent Composer constraint liability for a single diagnostic feature. With no downstream consumers, the failure surface is entirely untested in the wild.

Key questions for the requester:

1. What is the actual need — debugging our own response cache (TTL, key, HIT/MISS), or verifying CDN behavior? Neither is served by this package.
2. Which layer owns cache truth today: CDN edge, response-cache middleware (e.g. spatie/laravel-responsecache), or the Redis store?
3. What diagnostic surface is required — response headers, Telescope/log channel, or an internal admin UI? Only the header surface resembles what this bundle did.
4. Who is cleared to see cache keys and hit rates — internal-only, or potentially public responses?
5. Is a 1–2 day Laravel-native middleware build acceptable versus spending that time on observability tooling already in the stack (Telescope, APM, CDN analytics)?

Integration Approach

Stack fit — mismatch across every layer.

Migration path — replace, don't port.

1. Reject the dependency and log the decision as "not applicable — Symfony-only, archived" so it does not resurface in future procurement scans.
2. Spec a CacheInfoMiddleware. Laravel-native terminable middleware that reads the resolved response's cache headers and appends X-Cache-Status, X-Cache-Key, X-Cache-TTL — the same surface the bundle exposed, expressed idiomatically.
3. Register conditionally. Laravel 11: appendIf(...) in bootstrap/app.php; Laravel 10: gate in Kernel::middleware on a config flag and app()->isLocal().
4. If genuine Symfony-side parity is needed (e.g. a shared gateway already running Symfony HttpCache), evaluate maintained alternatives inside that Symfony service — not inside the Laravel app. FOSHttpCache and Symfony's own HttpCache docs are the live references there.

Compatibility.

• No extra.laravel block → auto-discovery will register nothing.
• Composer resolution against Laravel 10/11 will likely fail or force downgrades elsewhere; treat any "successful" install as unvalidated, not working.
• No confirmed PHP 8.2/8.3 coverage, no deprecation testing.

Sequencing (proposed, ~2.5 engineer-days).

1. Requirement clarification with product + platform (0.5 day).
2. Spike the middleware with header-only output behind a flag (1 day).
3. Security review — ensure diagnostic headers cannot leak into publicly cached responses (0.5 day).
4. Ship gated to non-production; document the runbook (0.5 day).

Operational Impact

Maintenance.

• Adopting the package means owning a fork in perpetuity: archived upstream, no PR path, no release cadence. Total cost of ownership far exceeds a small in-house middleware.
• A first-party middleware sits on the squad's normal review and upgrade cycle, and moves with Laravel major versions — a materially better TCO story.

Support.

• Zero community: 1 star, 0 dependents, no maintainer. Any incident becomes unbounded-time debugging of unfamiliar Symfony internals inside a Laravel runtime — the worst possible incident shape.
• In-house middleware has an identifiable owning squad and code that is idiomatic to the team.

Scaling.

• Header-only diagnostics are negligible per-request cost. Avoid serializing store payloads or cache keys containing values into every response.
• Watch for header bloat on high-fanout endpoints, and for intermediaries caching diagnostic headers. Set Cache-Control: no-store on responses carrying them, or restrict to internal traffic.
• If we later want trend visibility, aggregate from logs/metrics (Prometheus/Grafana, APM, CDN logs) — not from per-request introspection.

Failure modes to plan around.

• Silent no-op: bundle installs but registers nothing → false confidence that diagnostics are live.
• Composer constraint drift: future Laravel upgrades blocked by legacy Symfony pins.
• Information disclosure: cache keys and hit ratios exposed on public responses.
• Edge poisoning of debug headers: diagnostics cached at the CDN and served to other users.
• Middleware exception breaking the request path: wrap in try/catch and fail open — diagnostics must never 500 a user request.

Ramp-up.

• Low for a Laravel engineer to build the replacement (middleware + config + test ≈ 0.5 day to competence).
• High for anyone asked to understand this bundle: Symfony bundle conventions plus legacy Symfony HttpCache internals, for a feature the platform team can reimplement in a day.

TPM recommendation: The 0.0025 score is directionally correct. Reject as a dependency; treat it as a read-once reference. If the diagnostic need is confirmed, allocate ~2 engineer-days to a Laravel-native cache-info middleware, gated to non-production, with a security sign-off on header exposure.