Twig Injection Bundle Laravel Package

Product Decisions This Supports

• Plugin/extension architecture (build vs. buy): the bundle lets services contribute or override Twig templates via event listeners instead of hard-coding paths in twig.yaml or copy-pasting vendor templates into the app. That directly supports a roadmap item like "third-party modules can ship UI without patching core."
• Theming / multi-tenant UI: a natural fit if we need per-tenant, per-plan, or per-white-label template resolution decided at runtime. This is a feature-scoping lever — ship one codebase, vary presentation by event subscriber rather than by deploy.
• Progressive UI rollout: because resolution happens at render time, template selection can be driven by feature flags, enabling staged rollouts of layout changes without a release branch.
• Vendor bundle customization: reduces the "fork the vendor bundle to change one template" pattern, which is a recurring maintenance tax. PM-relevant because it lowers the cost of staying on upstream versions.
• Framework reality check: this is a Symfony bundle, not a Laravel package. In a Laravel codebase it only becomes relevant if we're running Twig via rcrowe/twigbridge and willing to carry Symfony's EventDispatcher and bundle bootstrapping. The actual decision it informs is narrower: "do we accept a Symfony component in our Laravel stack to solve template extensibility?" For a Blade-first app, the equivalent decision is View::addNamespace / a custom FileViewFinder / view composers — cheaper and native.
• Upgrade-cost signal from v3.0.0: the new major drops PHP 7 and Symfony 3. That is a good sign for security posture (legacy runtimes retired) and a neutral-to-negative sign for upgrade economics — a single-maintainer project cutting majors means consumers absorb breaking changes on the maintainer's schedule. Factor this into any "depend vs. reimplement" call rather than into the feature decision itself.

When to Consider This Package

Adopt (or, more likely, borrow the pattern) when all of the following hold:

• The application is Symfony 5/6/7 with Twig — this is the intended and only well-supported context. v3.0.0 dropped Symfony 3 and PHP 7, so we sit comfortably inside the supported window; there is no reason to consider this on a legacy PHP 7 / Symfony 3 estate at all.
• We have, or are about to have, a plugin/module/theme model where extensions must inject templates without editing central config.
• We can absorb the dependency: MIT license, single-vendor maintenance, no dependents — assume we may have to fork and own it. Pin the major (^3.0): v3 is a breaking release, so an unpinned constraint is a future incident.
• Rendering performance is not a hard constraint; event dispatch per template resolution adds overhead worth measuring on hot paths.

Look elsewhere or build in-house when:

• Laravel/Blade stack — use native view namespaces, view composers, or a custom view finder. Do not pull in a Symfony bundle for this.
• Native Symfony features already suffice — bundle template inheritance (@Bundle/... overrides) and Twig namespaces cover most "override a vendor template" needs without a new dependency.
• Maintenance risk is unacceptable — handful of stars, 0 dependents, one maintainer, sparse documentation. v3.0.0 shows the project is alive but not staffed: it is a modernization bump, not a support commitment. Treat it as a reference implementation, not a foundation.
• You need guaranteed API stability or support — nothing on offer, and the major-version cut is the clearest evidence yet that the public surface can move.

Practical recommendation: prototype against it to validate the extension model, then decide whether to depend on it or reimplement the ~event-subscriber-plus-loader logic internally (likely a day or two of work) so we control the upgrade path. v3.0.0 does not change that calculus — it slightly reinforces it.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed Symfony library that lets modules inject Twig templates through events rather than config edits. Strategically it de-risks the plugin/theming roadmap by removing the need to fork vendor code. Tactically it is low-cost and low-risk — but also low-signal: a handful of stars, no downstream dependents, one maintainer. The v3.0.0 release (PHP 7 and Symfony 3 support removed) confirms the project is maintained, not that it is supported. Frame it as a validated pattern we can adopt cheaply, not as infrastructure we bet the roadmap on.

To engineering: The value is the pattern — an event-driven hook into template resolution — not the code. If we're on Symfony + Twig, spend a day evaluating it against native bundle inheritance; if the fit is good, adopt at ^3.0 (the major drops PHP 7 / Symfony 3, so verify our runtime floor before upgrading) and keep a fork ready. If we're on Laravel/Blade, close the ticket: this is the wrong ecosystem, and the native equivalents are simpler and better supported.