Supercache Bundle Laravel Package

Product Decisions This Supports

• Framework fit decision (blocking): pablok/supercache-bundle remains a Symfony bundle, not a Laravel/PHP package that can be adopted into a Laravel application. The new 0.6.0 release does not change this: its PRs are development-environment work (Docker instead of Vagrant), dev-tool updates, and removal of Symfony 4.2 deprecations. None of these add Laravel compatibility or a supported integration path. Any roadmap item assuming a drop-in Laravel cache layer should stay re-scoped.
• Build vs. buy vs. adopt: This remains a “do not adopt” data point, not a live option. The 0.6.0 release is housekeeping, not a feature or security release. If the underlying need is HTTP response caching (full-page cache, TTL/ESI, cache warming, invalidation), the realistic paths remain a maintained Laravel package, framework-native middleware plus cache headers, or edge/CDN caching.
• Dependency governance: Useful as a worked example for package intake: a new version can still fail gates when the changes are only dev tooling and framework-deprecation cleanup, with no feature work, no security patch path, no meaningful ecosystem validation, and a single-maintainer bus factor. A version bump should not reset the evaluation.
• Roadmap hygiene: Supports closing the associated ticket/ADR as “rejected — framework mismatch + unmaintained/negligible validation,” and recording the actual requirement (e.g. “reduce origin load on catalog pages”) so it can be re-pointed at a viable solution.
• Use cases it legitimately serves: reference reading only — reviewing how a Symfony cache bundle is structured, or as prior art if writing an internal caching bundle. The 0.6.0 release adds little beyond dev-environment and deprecation cleanup.

When to Consider This Package

• Only if you already operate a legacy Symfony application where this bundle is pinned in composer.lock, it is working, and the migration cost demonstrably exceeds the risk of carrying a low-activity dependency. Even then, the correct action is a planned removal, not a new adoption.
• Only as a read-only reference for design patterns, with the explicit understanding that no code is copied and no dependency is added.
• Look elsewhere if any of the following is true (all are true for most teams): you are on Laravel; you need PHP 8.x compatibility guarantees; you need a security patch path; you need a maintainer who responds to issues; you need test/CI signal or documentation; you need ecosystem validation (0 dependents, 1 star means no external validation). The 0.6.0 release does not satisfy these — dev tooling and Symfony 4.2 deprecation cleanup are not evidence of a support commitment.
• Viable substitutes to evaluate instead: Laravel’s cache and middleware primitives with HTTP cache headers, a maintained response-cache package with an active release cadence, Symfony’s own HttpCache/Cache component or FOSHttpCache for Symfony shops, and edge/CDN caching for most read-heavy page workloads.

How to Pitch It (Stakeholders)

For executives (one paragraph): We re-reviewed pablok/supercache-bundle after its 0.6.0 release and recommend against adoption. It is still a Symfony-specific bundle, so it does not fit our Laravel stack. The 0.6.0 changes are limited to development-environment tooling, dev-tool updates, and removal of Symfony 4.2 deprecations — not Laravel compatibility, new caching features, or security maintenance. The project still has negligible ecosystem validation (0 dependents), a single-maintainer bus factor, and no credible support path. Adopting it would add permanent upgrade and audit risk in exchange for functionality we can obtain from a maintained package or our CDN in less time. Recommendation: keep the evaluation closed, record the underlying caching requirement, and fund a short spike against a maintained alternative.

For engineering (talking points): Framework mismatch is disqualifying before any code review — it is a Symfony bundle, not a Laravel package. The 0.6.0 release is not a reason to reopen the evaluation: Docker/Vagrant dev-environment changes, dev-tool updates, and Symfony 4.2 deprecation cleanup are housekeeping, not evidence of PHP 8 compatibility work, CVE response, or issue triage. Zero dependents means no field reports. Treat this as documentation of the problem space and prior art, not a dependency; if the team wants the pattern, reimplement it against the framework’s native cache contracts, which we already support and can test.