pablok/supercache-bundle
A Symfony bundle that integrates the SuperCache caching library into your application, providing service configuration and cache management for faster page delivery. It wires caching services into the Symfony container so you can enable, configure, and use SuperCache with minimal setup.
SupercacheBundle is a Symfony bundle (not Laravel — the stack mismatch is the first thing to flag) that wraps Symfony's HttpCache store with a filesystem-backed cache implementation. The intent was to provide a drop-in StoreInterface for HttpCache that persists full HTTP responses to disk, giving you reverse-proxy-style caching without standing up Varnish or a CDN edge. The functional surface is small and well-bounded: a cache store, a config tree, and a compiler pass — it does not patch the kernel, intercept the event dispatcher, or override the routing layer, which is exactly the profile you want in an infrastructure dependency.
Architecture fit. The bundle plugs into framework.http_cache via a custom store.service id. That is a sanctioned extension point in Symfony, so the coupling to the framework is to a public contract rather than internals. The conceptual model — HttpCache + pluggable store — has been stable since Symfony 2.8. For a project already using the Symfony HttpCache kernel wrapping pattern, the adoption cost is a few lines of YAML.
What 0.6.0 changes. Effectively nothing at the runtime boundary. The release is the first in years, and its contents are exclusively development-environment hygiene: Docker replaces Vagrant (#2), dev tooling versions are refreshed (#3), and Symfony 4.2 deprecation notices are cleaned up (#4). There is no new feature, no composer.json constraint widening, no PHP 8.x support, no Symfony 5/6/7 compatibility work, and no change to the StoreInterface implementation, the config tree, or the compiler pass. The deprecation-removal PR is a signal that the maintainer tracks Symfony 4.2 — a 2018 release line — which if anything confirms the ceiling rather than lifting it. Treat 0.6.0 as evidence the repository is not entirely abandoned, not as evidence it is maintained against a current stack.
Integration feasibility. Straightforward for a Symfony 4.x-era application. The practical blocker is still version drift: composer.json constraints will almost certainly not permit Symfony 5/6/7, and the CacheInterface / StoreInterface signatures in newer Symfony releases changed in ways this store implementation will not satisfy. 0.6.0 does not close that gap, so it remains a fork-and-patch exercise rather than a composer require.
Technical risk. High, concentrated in three places. (1) Bus factor: single maintainer, near-zero dependents, and a multi-year dormancy that one release does not undo — the burst of activity may be a one-off backfill rather than a resumption of stewardship. There is still no second maintainer to route a CVE to. (2) Unpatched dependency graph: the dev-tool refresh in #3 does not constitute a security review of the runtime graph, and the release window gives no assurance about transitive versions. (3) Correctness risk in a caching layer is asymmetric — a cache store bug doesn't degrade gracefully, it serves wrong bytes with a 200. Disk-based HTTP caches are also vulnerable to stampede and lock contention under concurrency, and nothing in these three PRs touches concurrency behavior.
Key questions for the team.
symfony/http-cache, FOSHttpCache) covered the gap since 2018?StoreInterface implementation really large enough to justify inheriting a package with this history? (Spoiler: it is probably ~200 lines.)Stack fit. None, as stated. This is a Symfony bundle; in a Laravel application it cannot be installed meaningfully — Laravel has no bundle/kernel-wrap concept for HttpCache stores, and the service definitions and DI compiler pass have no analogue. If the target is Laravel, this is a non-starter and the correct answer is Laravel's own response cache (spatie/laravel-responsecache or ResponseCache middleware) or a CDN. 0.6.0 does not change this in any way. If the target is Symfony, the fit is real but time-boxed to Symfony 4.x.
Migration path. Two viable paths, and I'd only sanction one:
composer.json version constraints. Plan for a ^0.6 VCS constraint pointing at our fork.The 0.6.0 release slightly softens the "the build dies on a fresh machine" scenario, because the tag exists to pin against — but a pinned tag on an unmaintained branch is not a strategy; it is a deferred rewrite.
Compatibility. Verify explicitly before commitment: PHP version constraints (still likely capped at PHP 7.x, blocking our 8.x baseline — #3 updated dev tools, not runtime requirements), symfony/http-kernel and symfony/http-foundation version ranges, and whether the store implements the current StoreInterface method signature including cleanup(). #4 removing Symfony 4.2 deprecations tells us the floor, not the ceiling. Any of these failing converts the integration from "config change" to "small rewrite," which should be priced into the estimate now rather than discovered in sprint.
Sequencing. Unchanged, with one addition. (0) Re-read composer.json and the changelog at the 0.6.0 tag to confirm the constraints were not widened — the release notes are dev-only, so assume they were not. Then: (1) spike the store against our actual Symfony version in a throwaway branch, 30 minutes; (2) if it wires up, port to internal namespace with unit tests for cache hit, miss, invalidation, and purge; (3) load-test concurrently to inspect lock behavior under stampede; (4) ship behind a feature flag with the HttpCache wrapper toggled by environment; (5) measure. If the spike fails at step 1, stop — the extract path is the only remaining option and it's cheap enough that a failed spike is a good outcome.
Maintenance. Still the decisive factor. 0.6.0 partially de-risks the "archived forever" narrative but does not de-risk the substance: one maintainer, no release cadence we can rely on, no demonstrated capacity to absorb a framework upgrade, and a release whose content is a DevEx refresh rather than a compatibility commitment. Every Symfony upgrade, every PHP minor bump, and every security scan that flags a stale transitive dependency is still our incident. The nominal license is MIT and permissive, but the real license cost is "we now maintain a fork" — a cost that must be assigned to a named owner or it will be paid in production at 3 a.m. by whoever is on call.
Support. Marginally better than zero — the maintainer is demonstrably alive as of 0.6.0 — but not supportable for planning. No SLA, no documented deprecation policy, no indication of a support window. Internal engineers unfamiliar with the code will have only the source, three PR titles, and whatever tests we write. Treat any documentation we produce as the sole runbook.
Scaling. Unchanged and unrelated to this release. Disk-backed HTTP caching has known shape and known cliffs: it scales well on a single node and poorly across a fleet unless you mount shared storage, at which point filesystem latency and lock contention dominate. There is no cluster invalidation story here — purge semantics are per-node, so cache correctness under horizontal scaling requires out-of-band coordination we'd have to build. For anything beyond a handful of app servers, this is a stepping stone to a reverse proxy (Varnish, nginx proxy_cache) or a CDN, not a destination.
Failure modes. Rank them in the risk register: (1) silent mis-cache — wrong content served with a 200, hardest to detect, needs response-hash canaries or synthetic checks; (2) stale-after-deploy — old template bytes served because disk cache survived a release, mitigated by a deploy-time purge step that must be in the runbook; (3) disk exhaustion — no eviction visibility, needs a size alarm and a cap; (4) upgrade breakage — a composer update silently fails to resolve or resolves to a broken state; (5) stampede on cold cache after purge, which will look like a database outage. Note that #4 in the release removed deprecation notices for Symfony 4.2 specifically — the reverse risk is that a future cleanup pass introduces behavioral change with no test coverage we control.
Ramp-up. Low to understand, moderate to operate safely, high to own. Any senior PHP engineer can read the store implementation in an afternoon. The expensive part is the surrounding discipline: purge hooks in the deploy pipeline, cache dashboards, disk alerts, and the institutional knowledge that this component is lightly maintained and must never be upgraded casually.
Recommendation. Do not adopt as a dependency. The capability it provides is small, achievable in-house in a day or two, and — despite 0.6.0 — the package remains single-maintainer, near-zero-dependent, still ceilinged at Symfony 4.x / PHP 7.x, and, per the architecture description, built for the wrong framework if the target really is Laravel. The score of 0.1025 is essentially unchanged: three dev-environment PRs are a weak signal against a seven-year dormancy and no forward compatibility commitment. If the underlying goal is page performance, evaluate a Symfony-native or CDN path first; the buy-vs-build verdict here is build, and the fork-and-own verdict is only marginally better.
How can I help you explore Laravel packages today?