Twig Cache Key Bundle Laravel Package

Product Decisions This Supports

Short answer: it mostly supports a "do not adopt" decision — and it surfaces a real but narrow infrastructure question worth answering.

• Build vs. buy vs. build-in-house (5 lines). The capability — making compiled-template cache keys relative rather than absolute-path-derived — is worth roughly 20–50 lines of code in your own app. This package is the "buy" option, and the buy option is dead. The decision it supports is: build in-house if the problem exists, ignore otherwise.
• Deployment architecture decision. The real question behind this repo is whether compiled template caches can be shared between a CI/build container and a runtime container. If your product ships container images with pre-warmed caches, absolute-path cache keys silently invalidate them on every deploy. That is a legit roadmap input for platform/infra work.
• Cold-start performance roadmap. Relevant only if you can measure template compilation as a material share of first-request latency (typically only at high template counts, e.g., 500+ Twig templates, or on scale-to-zero/serverless runtimes).
• Not a Laravel decision. This is a Symfony bundle (*Bundle naming, service-container registration), and Twig is not Laravel's default engine — Laravel ships Blade. Even with a Twig bridge installed, this bundle will not register. The "Laravel/PHP package" framing in the request is factually wrong for this repo, and that alone should stop it at intake.
• Use cases where the concept, not the package, applies: Docker image build-time cache warmup, read-only container filesystems, blue/green deploys wanting shared cache artifacts, reproducible builds.
• Counter-signal for the decision log: 0 stars, 0 dependents, last release 2016-03-09, archived. That is a portfolio-level "no," independent of technical merit.

When to Consider This Package

Adoption criteria — all would have to be true, and even then it fails the last one:

• You run a Symfony application (not Laravel) pinned to Symfony 2.x/3.x and Twig 1.x.
• You deploy compiled template caches across environments with differing absolute paths.
• You accept vendoring or forking an unmaintained dependency.
• You have an owner willing to carry a security and compatibility burden indefinitely.

Given the archive date, there is no realistic Twig 2/3 or Symfony 4+ compatibility story, no CVE response path, and no upstream to escalate to.

Look elsewhere when:

• You're on Laravel — use php artisan view:cache at build time and keep view.compiled on a path that is identical in build and runtime. Solved.
• You're on modern Symfony — configure twig.cache to a relative or build-stable directory and warm the cache during the image build. Also solved, natively.
• You want a maintained dependency — there is none here to prefer; the honest comparison set is "your own code."

Where the package is genuinely informative: it is a clean, ~2016-era worked example of the problem statement. Read the source for the idea; do not put it in composer.json.

How to Pitch It (Stakeholders)

Recommendation: no action, no dependency. This is a 2016 Symfony bundle with zero stars and zero dependents, archived and unmaintained for roughly a decade. It does not target Laravel. Adopting it would add supply-chain and maintenance risk to buy a capability that costs a few days to implement correctly in-house — and which modern Symfony and Laravel both address natively through cache-path configuration and build-time cache warmup.

If template compilation latency is a measured problem (bring numbers: p95 first-request time, template count, cold-start frequency), the pitch is a small platform task, not a dependency: pin the compiled-view path to a build-stable directory and warm the cache during image build. Budget: days, not weeks; no ongoing ownership cost.

If it is not a measured problem, the pitch is to close the ticket. The only durable output of this evaluation is a line in the decision log: "Relative template cache keys — solved natively; no third-party dependency required."