Twig Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for runtime-editable templates. This package answers exactly one question: "can we let non-engineers change rendered output without a deploy?" It is a thin, single-purpose integration — a Twig loader whose source is a database row. Framed honestly, the decision is not "adopt this," it's "do we own this capability at all, and if so do we start from this ~100–200 LOC reference or from scratch?" It is a head start on the build option, not a dependency you consume.
• Self-serve customization roadmap. Unlocks a concrete feature line: tenant- or merchant-level overrides of transactional emails, notification copy, invoice and PDF layouts, and branded content fragments. That is a recurring "can we change this without a ticket?" request from Sales, Support, and Marketing. Size it in support-hours-per-month before committing — that number is the business case.
• Multi-tenant data modeling direction. Forces an early, cheap-to-make / expensive-to-unwind decision: are template overrides per-tenant rows scoped by tenant ID, or per-environment config? The bundle's persistence model effectively becomes a schema commitment the moment you adopt the pattern.
• Ops toil reduction and release cadence. Quantifies a real, current cost: every copy tweak consumes a PR, review, CI run, and a deploy slot. A DB-backed loader converts those into a content operation. This is the most defensible ROI framing available.
• Tooling investment scoping. If we pursue it, we are implicitly funding far more than a loader: an editor UI, preview-before-publish, versioning and rollback, and an audit trail. The package covers roughly 10% of that surface. Use it to size the remaining 90% honestly in a roadmap conversation rather than discovering it mid-sprint.

Caveat to lead with: despite being filed as a Laravel/PHP package, this is a Symfony bundle. It assumes a Symfony HttpKernel, DI container, Doctrine, and Twig. In a Laravel/Blade codebase it is not installable as a dependency. The pattern and likely one class (LoaderInterface implementation) are portable; the packaging is not.

When to Consider This Package

Evaluate it when all of the following hold:

• The target service is Symfony + Twig + Doctrine. Genuinely non-negotiable — the bundle is container wiring, and that machinery does not exist in Laravel.
• There is a real, recurring need for runtime template changes by non-developers — measured in tickets, not hypothesized in a planning doc.
• You are prepared to vendor or fork. Zero stars, zero dependents, and a score of zero mean no community, no issue triage, no upgrade path, no vendor to escalate to. Treat it as permissively licensed sample code, not composer require-and-forget infrastructure.
• You will build the surrounding machinery yourself: cache invalidation on write, versioning/rollback, preview, and an authorization model for who may edit.
• Authorship is restricted to trusted staff. Twig stored in a database turns DB write access — or an admin-panel bug — into arbitrary server-side execution. The sandbox extension is a separate add-on with its own sharp edges; do not assume this package provides isolation.

Look elsewhere when:

• Laravel/Blade is the stack. Wrong framework. Portable pattern, unusable code. Budget 1–3 engineer-days for a conceptual port (Eloquent source, Laravel cache, TwigBridge registration) before any editor work.
• Templates are developer-owned. If engineers edit them, filesystem + Git is strictly better — versioning, review, diffs, and rollback come free.
• You actually need a CMS. Editorial workflow, scheduling, localization management, rich preview, roles — buy a headless CMS rather than growing one outward from a loader.
• Templates are customer-authored or untrusted. Do not execute customer-supplied Twig. Use a deliberately constrained template language or a sandboxed renderer.
• You require vendor support or an SLA. There is no vendor. Budget ownership from day one.

How to Pitch It (Stakeholders)

For executives: A small open-source component that would let business teams update customer-facing text — emails, notifications, invoice layouts — without waiting on an engineering release. The strategic value is the capability, not the library, and the library has effectively no community behind it. If we pursue it, we own the code and must also fund the pieces that make it safe and usable: an editor, preview, version history, and access controls. Recommendation: a timeboxed spike, not a strategic dependency. Validate demand first by counting current template-change tickets per month.

For engineering: Symfony/Twig/Doctrine only — not applicable to our Laravel services as a dependency. It's a Twig loader backed by a Doctrine entity; small, readable, unmaintained. Treat it as a reference implementation. Three decisions gate adoption: (1) caching and invalidation when rows change — isFresh() correctness is where these loaders live or die; (2) tenant scoping baked into the schema; (3) the security boundary — DB-stored Twig is remote code execution for anyone with write access to that table, so the editor needs real authZ, audit logging, validate-on-save, and a serious look at the sandbox extension. Realistic effort: the loader is a day; the safe, usable product around it is weeks.

The one-line ask: fund a short spike to confirm demand and size the editor, versioning, and security work — the loader itself is the easy part, and this package is only useful to us as a head start on it.