Weave Code
Twig Explorer Bundle Laravel Package
knplabs/twig-explorer-bundle
Symfony bundle that integrates Twig Explorer, providing a browser-based interface to browse and inspect Twig templates. Quickly view template source, inheritance, and structure to debug and better understand your views during development.
Find your way through the twig extensions
Frequently asked questions about Twig Explorer Bundle
- Can I install knplabs/twig-explorer-bundle in a Laravel application?
- Not as a native package. It is a Symfony bundle that ships a Bundle subclass, a DI extension, tag-based compiler passes, and routes registered through Symfony's routing component, none of which Laravel understands. Making it run would require a service-provider shim that re-registers routes and translates Symfony's tagged-service introspection into the Laravel container. Twig itself is not native to Laravel either, so you would also be pulling in a third-party bridge such as rcrowe/twigbridge. For a Laravel roadmap the practical answer is no.
- How do you install and enable Twig Explorer Bundle in Symfony?
- You add it with Composer as a development dependency and register the bundle in your kernel or bundles.php for the dev and test environments only. Routes are exposed through the bundle's routing configuration, so you typically import them under a dev-only prefix. Older docs assume Symfony 2.8 through 4.x and the corresponding bundle registration conventions. On a modern Symfony 6 or 7 application, expect Composer resolution to fail on the version constraints.
- Is knplabs/twig-explorer-bundle still maintained?
- No. The repository is archived, has roughly 23 stars and zero dependents, and targets the PHP 7.x, Symfony 2.8–4.x and Twig 1–2 era. Archived status means no security patches, no compatibility work, and no upstream to fix issues you hit. Most dependency policies will flag it automatically as abandoned.
- Does Twig Explorer Bundle work with Twig 3 and PHP 8.2?
- Almost certainly not without patching. The bundle's reflection paths assume Twig 1 and 2 API signatures, and Twig 3 changed getFunctions and getFilters return types, deprecated several NodeVisitor behaviours, and added Bundle::getPath requirements. Composer constraints for PHP expect the 7.1 era and for Symfony expect 2.8 through 4.x, so resolution will fail on PHP 8.2 and Symfony 6 or 7. A forced install would leave you maintaining a fork of dead code.
- How is this different from Symfony's debug:twig and lint:twig commands?
- Functionally it exposes largely the same metadata: registered templates and their paths, plus filters, functions, tests, tags, globals and loaded extensions. The difference is that Twig Explorer presents it in a browsable web UI instead of console output. That is a developer-convenience delta rather than a platform capability, and Symfony's first-party CLI commands are maintained and already installed. Most teams are better served by debug:twig and lint:twig.
- Is it safe to expose Twig Explorer in production?
- No. The bundle exposes an in-process HTTP surface that enumerates template paths, extension names and globals, which is a non-trivial information-disclosure vector if the dev-only gate is ever misconfigured. If you run it at all, keep it require-dev, restricted to the dev and local environments, behind an authenticated firewall and an IP allowlist. Never enable it in shared staging or production.
- What are the alternatives for inspecting templates in a Laravel app?
- Laravel already ships first-party tooling: artisan view:list, view:cache and view:clear, Laravel Telescope for runtime inspection, and documented Blade component APIs. If you genuinely need Twig introspection because you run Twig through a bridge, reflect over Twig\Environment::getExtensions() in a small dev-only command. That is roughly a day's work and gives you full ownership of the surface area with zero supply-chain risk.
- How would I build the equivalent Twig inspection command myself?
- The extraction logic is thin. Iterate Twig\Environment::getExtensions(), read getFilters(), getFunctions(), getTests() and getTokenParsers() from each extension, and reflect on GlobalsInterface for globals. Wrap that in an Artisan command such as php artisan twig:inspect or a dev-only route, and print the results as a table. You end up with the same information the bundle surfaces, minus the archived dependency.
- Will dependency scanners or CI policies block this package?
- Usually yes. Archived and abandoned packages are commonly flagged by Composer audit tooling, and this one has no security patch path at all. Because it is dev-only the runtime risk is lower, but CI policies frequently treat abandoned dev dependencies the same as production ones. If your organisation has a written policy on archived dependencies, this package is a textbook case for applying it.
- What is the risk of adopting an archived bundle with zero dependents?
- Zero dependents means no field validation and no community pressure to fix issues; your organisation would become the sole consumer of dead code. That risk is asymmetric: the upside is a convenience UI you could rebuild in a day, and the downside is an unpatched component in your supply chain. Validate the actual user problem first, whether it is extension discovery during onboarding, template debugging, or a pre-upgrade audit, because each has a maintained first-party answer. If you need the functionality, replace it rather than adopting it.
Weaver
How can I help you explore Laravel packages today?