Weave Code
Twig Extension Proxy Bundle Laravel Package
markup/twig-extension-proxy-bundle
Symfony bundle that adds a Twig extension proxy, routing function, filter and test calls through one service so extensions can be decorated, lazy-loaded or overridden without touching your templates.
A Symfony bundle that can provide lazy access to simpler, more common kinds of registered Twig extensions.
Frequently asked questions about Twig Extension Proxy Bundle
- Can I install markup/twig-extension-proxy-bundle in a Laravel app?
- No. It is a Symfony bundle built on Symfony's Bundle class, DependencyInjection compiler passes, and service tagging for Twig\Extension\ExtensionInterface services. Laravel does not use symfony/dependency-injection, symfony/http-kernel, or the bundle system, so Composer requiring it will not wire anything. You can read and port the proxy logic, but the package itself is not adoptable as a Laravel dependency.
- What problem does a Twig extension proxy actually solve?
- It defers construction of registered Twig extensions until one of their filters, functions, or tests is actually invoked. Instead of instantiating every extension on each request, a proxy is placed into the Twig environment and resolves the real extension lazily from the container. That helps when extension constructors are expensive or perform I/O. The pattern is small; the Symfony bundle is just one implementation of it.
- Does this bundle work with Laravel's Blade templating engine?
- No. Blade compiles templates to plain PHP and registers directives as static strings, so there are no Twig extension objects to proxy. Twig only appears in Laravel through a third-party bridge, which has its own extension registration contract and does not read Symfony bundle configuration.
- How would I port the lazy Twig extension proxy pattern to Laravel?
- Implement a TwigServiceProvider or use the Twig bridge's extension contract, and wrap each expensive extension in a proxy whose getFilters(), getFunctions(), and getTests() return closures that resolve the real extension from Laravel's container. Bind the proxy with a closure or use a DeferrableProvider-style registration so construction is deferred. Keep the proxy thin and make sure it forwards metadata such as getName() correctly for your Twig version. Measure before and after.
- Is the bundle compatible with Twig 3 and newer?
- There is real version-drift risk. Twig 3 deprecated or removed getName() from the extension interface, so a proxy that forwards getName() incorrectly can break Twig's extension registry. A proxy must also avoid eagerly calling getFilters(), getFunctions(), and getTests(), or it defeats the lazy optimization. Check the package's composer.json constraints and test against your exact Twig version before relying on it.
- How do I install and register this bundle in a Symfony application?
- Install it with Composer and enable it in config/bundles.php, the standard Symfony bundle registration path. The bundle relies on service tagging and compiler passes to discover Twig\Extension\ExtensionInterface services, so your extensions need to be registered as services in the container. Verify the exact service IDs and configuration against the repository, since the README excerpt here is empty.
- Is markup/twig-extension-proxy-bundle maintained and safe for production?
- Treat it as unmaintained until proven otherwise: 0 stars, 0 dependents, a single-org publisher, and no downstream validation. Supply-chain blast radius is negligible because nobody depends on it, but that also means the code has not been peer reviewed outside the author. Check the last commit date, open issues, and branch activity before considering it, and prefer porting the pattern over adopting the package.
- How do I know if lazy-loading Twig extensions will improve my app's performance?
- Profile first. Use Blackfire, XHProf, or Laravel Telescope if you are in Laravel to confirm that Twig extension instantiation is actually in the hot path. If the heavy extensions are yours, fix their constructors instead of proxying them. A proxy helps only when construction cost is real and avoidable; otherwise it adds indirection.
- Can I override or decorate a Twig extension without forking the bundle?
- In Symfony you can decorate the extension service or use lazy service definitions, and the bundle's proxy is one way to do that. In Laravel with Twig, decorate or rebind the extension through the bridge's service provider, or wrap it in your own proxy bound with a closure. Avoid editing vendor code; keep the override in application code so upgrades stay possible.
- What are the alternatives to this bundle for Laravel or Symfony projects?
- For Symfony, the bundle itself or native lazy service definitions are the direct options. For Laravel, there is no drop-in equivalent; the practical alternatives are porting the proxy pattern into a Twig service provider, fixing expensive extension constructors, or avoiding Twig entirely in favor of Blade. If the intake target is Laravel and you are on Blade, the correct answer is not applicable.
Weaver
How can I help you explore Laravel packages today?