- Does Twig Inspector work in a standard Laravel Blade application?
- No. Twig Inspector hooks the Twig rendering pipeline, and Blade is Laravel's native engine, so there is no insertion point in a normal Blade app. It only becomes relevant if your Laravel application actually renders views through Twig, typically via rcrowe/twigbridge, or if you are debugging a Symfony service. For Blade codebases, Telescope, Debugbar, and Blade directives already cover the same debugging need.
- How do I install hec-franco/twig-inspector in a Laravel app using TwigBridge?
- Install it as a dev-only dependency with composer require --dev hec-franco/twig-inspector, pinned to a commit SHA rather than a floating constraint. There is no documented Laravel auto-discovery or config surface, so you will need a thin adapter service provider that grabs the shared Twig Environment and registers the inspector extension. Hard-gate enablement on APP_DEBUG or an explicit environment flag so it can never activate outside local or development.
- Which Laravel and Twig versions does Twig Inspector support?
- There is no documented version matrix, no stated Laravel support, and no evidence of extra.laravel.providers auto-discovery. Template inspectors tend to hook Twig internals such as extensions, node visitors, and the compiled-template cache, which makes Twig 2 to 3 upgrades and Symfony major bumps routine breakage points. Treat compatibility as unverified and pin both the package and your Twig version until you have tested the combination yourself.
- What exactly does Twig Inspector inject into the rendered HTML?
- It annotates rendered markup with markers, typically HTML comments or data attributes, identifying the template, block, and file:line that produced each fragment. The overview describes tracing templates, variables, includes, and blocks directly from the browser. Because the exact injection format and whether each marker type is toggleable are not documented, verify this in a spike before adopting it, especially if your front end is sensitive to extra markup.
- Is it safe to enable Twig Inspector in production?
- No, it should never reach production. Injected markup can corrupt JSON or XHR payloads, break snapshot tests, violate a Content Security Policy, and disclose internal template paths, so a single mis-set environment variable becomes an information-disclosure incident. Gate enablement in code on APP_DEBUG or an explicit env flag rather than relying on documentation, and keep the package strictly in require-dev with no production deployment path.
- What license does hec-franco/twig-inspector use?
- The repository reports NOASSERTION, meaning the license could not be identified. That is a hard legal gate before any code, even as a dev dependency, enters a commercial repository. If you want to use it, ask the maintainer to state a license in-repo or fork it into your organization with the licensing ambiguity resolved explicitly before writing an adapter.
- Does Twig Inspector ship a Laravel service provider with package auto-discovery?
- There is no documented Laravel support and no evidence of extra.laravel.providers auto-discovery, so you should assume manual wiring is required. In practice that means writing and owning an adapter, for example a TwigInspectorServiceProvider, that registers the Twig extension on the shared Environment and no-ops outside local or development. Budget roughly one to three engineer-days for that spike plus a test pass.
- Is Twig Inspector actively maintained and safe to depend on?
- The ecosystem signals are weak: about one star, zero dependents, a single maintainer, no release cadence, and no visible issue triage or CVE response path. Hooking the templating layer itself is exactly where you least want a small, unmaintained third-party dependency, because nobody upstream will fix a Twig or Symfony major-version break. Vendor it as a dev tool pinned to a commit SHA, or fork it so you control compatibility and security fixes.
- Does Twig Inspector interact with or invalidate the compiled Twig template cache?
- The package hooks Twig internals such as extensions, node visitors, and the compiled-template cache, so cache interaction is a real concern. Whether it invalidates or merely decorates compiled templates is not documented, and this determines whether a TwigBridge adapter is even feasible. Test cache warmup and clear behavior explicitly in your spike, and avoid enabling it in any environment where the shared compiled cache is reused.
- What are the alternatives to Twig Inspector for debugging Laravel views?
- On a Blade stack, Laravel Telescope, Laravel Debugbar, and Blade directives such as @dump already provide view-layer insight without hooking the engine. For Twig, the Symfony profiler and Twig's own debug extensions cover much of the same ground with better maintenance and clearer licensing. If your need is simply tracing which template rendered a fragment, roughly 50 to 100 lines of internal debug middleware you own is a cleaner, licensable alternative to adopting this package.