Twig Cache Purger Bundle Laravel Package

Product Decisions This Supports

• Deploy strategy: targeted vs. full cache invalidation. This bundle lets you purge one compiled Twig template instead of nuking the entire Twig cache directory. As a PM, that's a lever on how risky and how slow a template-level change is to ship. If your app compiles thousands of templates and warmup takes minutes, this changes the calculus from "batch template changes into a release train" to "ship a template hotfix now."
• Content-ops roadmap: editor-driven template publishing. If you're building or buying a CMS/theme editor, single-template purge is the missing primitive that lets a non-engineer change a partial and have it take effect without a full deploy. That's a feature decision (in-app template editing) gated on a technical decision (can we invalidate precisely?).
• Build vs. buy: strongly favors "build/vendor." The package is MIT, tiny, and single-purpose — it computes Twig's cache key for one template and deletes that file. Twig's cache key is deterministic (template name + environment hash) and documented behavior, so reimplementing it is roughly 50–100 lines with tests. Buy only if you want the Symfony wiring for free; the IP risk of building is near zero either way.
• Laravel reality check. This is a Symfony bundle, not a Laravel package. It has no Blade equivalent and cannot be installed into a Laravel app. For a Laravel shop, the decision it informs is "should we invest in selective compiled-view invalidation at all?" — and the answer is usually no, because view:clear is fast and deploys already invalidate compiled Blade. Treat this repo as a reference design, not a dependency.
• Multi-tenant / multi-theme applications. The clearest use case: tenant A edits their theme partial; you purge only tenant A's compiled template rather than forcing a global cold cache that penalizes every other tenant. Supports pricing/architecture decisions about per-tenant theming.
• Infrastructure investment. If selective purge is adopted, it justifies (or replaces) investment in cache-warming pipelines, blue/green deploy complexity, and cache-tag infrastructure. It's an argument for a smaller, cheaper invalidation story.
• Developer experience / internal tooling. Enables a "purge this template" admin button in staging or dev, shortening the edit-template → see-result loop without losing the compiled cache for every other template.

When to Consider This Package

Consider it when:

• You run Symfony with Twig, and template compilation/warmup is a measured bottleneck (cache warm is a meaningful share of deploy time, or a cold cache visibly degrades p95 latency).
• Template or partial changes legitimately happen outside a deploy — CMS webhooks, admin theme editors, per-tenant customization, A/B-tested partials.
• You already have an invalidation trigger (Symfony Messenger message, Redis pub/sub, webhook handler) and just need the "delete exactly this one" primitive.
• You have a large template catalog with a low-traffic or unevenly-warmed app where a full cache clear is disproportionately expensive.
• You want a short, auditable implementation to vendor into your own codebase — MIT license, small surface, no transitive blast radius.

Look elsewhere when:

• You're on Laravel/Blade — this doesn't apply; reimplement the concept against compiled views or skip it.
• debug is on in the relevant environment — Twig already re-checks template timestamps and reloads changed templates; you gain nothing.
• Your full cache clear + warm is already fast (seconds) and happens on every deploy — the marginal benefit is near zero and you're adding a maintenance dependency for nothing.
• You need broad or dependency-aware invalidation (invalidate every template that includes a given partial). This purges exactly one template; nothing here walks the include graph. Look at a custom Twig\Cache\CacheInterface, cache tagging, or a build-time dependency map instead.
• Adoption risk matters to you. 0 stars, 0 dependents, and a release metadata record that will need verification are real signals: no community, no third-party battle-testing, no guaranteed maintenance. If your policy requires a maintained or widely-adopted dependency, this fails regardless of technical merit — fork it and own it, or write it yourself.

How to Pitch It (Stakeholders)

One line for executives: A small, MIT-licensed utility that lets us invalidate a single compiled Twig template instead of clearing the entire template cache — reducing deploy risk and cold-cache slowdowns, at effectively zero license cost.

For engineering: It's a thin Symfony bundle around Twig's deterministic cache-key convention. Integration is small (register the bundle, inject a purger service, call it from your existing invalidation path). We can vendor it or reimplement in under a day with tests; either way the correctness risk is low because the cache key is documented Twig behavior.

Honest framing of the risk: It's unproven — no stars, no dependents, single maintainer, and the release metadata needs verification before we rely on it. That is not disqualifying for a ~100-line utility, but it is a reason not to make it load-bearing infrastructure. Recommendation: treat it as a reference implementation and pattern, not a strategic dependency. Pilot it on Symfony if we have a demonstrated template-cache pain point; skip it entirely on Laravel, where the concept doesn't map and the problem usually doesn't exist.