- Does TwigMetrics work with Laravel Blade templates?
- No. TwigMetrics is a Twig extension and template-metrics tool, so it does not operate on Blade templates in a stock Laravel application. If your team is Blade-only, the realistic option is to run it as a standalone CI-side tool against repositories that actually contain Twig templates. Do not introduce a Twig bridge into a Laravel app purely to satisfy a metrics tool.
- How do I install TwigMetrics in a Laravel project?
- Install it as a dev dependency with composer require --dev smnandre/twigmetrics, then pin ^1.1 and commit your composer.lock. TwigMetrics does not add a service provider or container coupling; you need to wire a command, define the template path, and generate a report artifact in CI. Verify the PHP and Twig version constraints in its composer.json against your runtime before merging.
- What metrics does TwigMetrics report for Twig templates?
- TwigMetrics reports template structure, lines of code, code style, complexity, and maintainability. It is designed as a static-analysis and dev-time tool, not a runtime profiler. Be aware that v1.1.0 included a Rework Dimension Metrics change, so baselines captured on v1.0.x may not be directly comparable to v1.1.0 output.
- Is TwigMetrics safe to run in production?
- TwigMetrics sits outside the request path and adds no runtime service provider or container coupling, so production risk is near zero. It is intended for developer machines and CI jobs, not as a production runtime dependency. The main operational concern is upgrade review, not runtime security.
- Which Laravel and PHP versions are supported by TwigMetrics?
- TwigMetrics has no Laravel version coupling because it is not a Laravel-first package and registers no service provider. You should check its composer.json for the exact PHP and Twig constraints and confirm they match your runtime before adopting it. The available context does not state a specific PHP or Twig version range.
- Can I use TwigMetrics in CI without failing builds?
- Yes. Start by adding TwigMetrics as an advisory, non-blocking CI step that publishes a report artifact. Do not gate CI on thresholds in the first pass, because the metric rework in v1.1.0 shows the numbers are not yet stable enough to fail builds on. Revisit threshold enforcement only after several further upstream releases show the metric definitions settling.
- Why did my TwigMetrics numbers change after upgrading to v1.1.0?
- v1.1.0 included a Rework Dimension Metrics item that changes how metrics are calculated inside a minor release. That means any baseline captured on v1.0.x may not be comparable to v1.1.0 output. Treat every 1.x bump as potentially output-changing and diff the report rather than trusting semver.
- Does TwigMetrics chart output work in an air-gapped CI environment?
- That is unconfirmed. The v1.1.0 Add Charts change implies HTML or visual output, but it is not documented here whether the output is self-contained or pulls JavaScript and CSS from a CDN. Verify this before relying on charts in an air-gapped CI job, or vendor the assets and fall back to text or JSON-style reports if needed.
- What are alternatives to TwigMetrics for Laravel template metrics?
- For Blade templates, TwigMetrics is not the right tool because it is Twig-specific. Look at Blade-aware linting and static-analysis approaches, or custom scripts that measure template size and structure, and use PHPStan or Psalm for PHP code rather than templates. For Twig codebases, Twig linting plus TwigMetrics or a small custom metrics script is a practical combination.
- Who maintains TwigMetrics and what is its support policy?
- TwigMetrics is maintained by a single maintainer, with v1.1.0 only the second tagged release and a three-PR history. There is no evidence yet of a backward-compatibility policy or a large test suite, so assume best-effort upstream support and plan for the possibility of vendoring a patch or forking. Name an internal owner to track releases so the dev dependency does not silently rot in composer.json.