- How do I install canvural/phpstan-blade-rule in a Laravel project?
- Install it as a dev-only dependency with composer require --dev canvural/phpstan-blade-rule. Then register it in your phpstan.neon by adding the package's extension/ruleset to the includes section and pointing paths at your Blade view directory. There are no application code changes, migrations, or service providers involved, so the install is purely additive.
- How do I configure which Blade views get analyzed?
- Configuration is done entirely in phpstan.neon rather than a Laravel config file. Add the package to includes, then use the standard PHPStan paths key with a glob such as resources/views or a narrower subdirectory so you can target analysis at specific areas. Because the view paths are configurable, you can start with one module or package and expand coverage once the finding volume is understood.
- Which PHPStan versions does canvural/phpstan-blade-rule support?
- The package is pre-1.0 and v0.4 makes no stability promise, so the composer.json constraint is the source of truth rather than an assumption that the latest PHPStan works. The rule hooks into PHPStan's rule registry and node/type resolution, so PHPStan major upgrades are the most likely source of breakage. Upgrade PHPStan first, then the Blade rule, and budget a compatibility check on every PHPStan bump.
- Does it work with my Laravel version?
- The rule analyzes compiled Blade templates, so it needs an illuminate/view version it declares support for. Check the illuminate/view and PHP constraints in the package's composer.json before adopting v0.4, since 0.x releases do not guarantee compatibility with the newest Laravel release on day one. Treat those constraints as authoritative and pin the version you validate against.
- Does this package affect production performance or add runtime dependencies?
- No. It is a dev-only PHPStan extension with zero production footprint: there is no service provider shipped at runtime, no database, no queue, and no config surface in config/. The only cost is extra work inside your static analysis job, which you can measure by running it on your largest view directory before enforcing it.
- Will I get false positives from view composers, View::share, or Blade components?
- Possibly, and false positives are the dominant risk rather than missed bugs, because Blade is dynamically typed by nature. Variables contributed by view composers, View::share, components, @each, and @php blocks are not always visible to the analyser. That is why the recommended approach is a report-only run first, triaging real undefined-variable bugs from dynamic-Blade noise, and baselining the latter with a small, commented ignoreErrors list.
- What changed with @include handling in v0.4?
- v0.4 ships an @include variable-scoping fix that removes a specific class of incorrect diagnostics around variables passed into or inherited by an included view. This is a false-positive reduction, not a new capability, so clean templates should behave the same. The practical benefit is a smaller ignoreErrors baseline, which makes the remaining findings easier to trust.
- How do I trial it in CI without blocking merges?
- Add the dev dependency and the phpstan.neon includes entry on a branch, then run it as a separate, non-blocking CI job so findings are reported as warnings only. Capture the initial finding count on the full view tree and decide whether the volume is worth the enforcement cost. Only promote it into the main quality gate once the noise level is acceptable; it should extend an existing PHPStan setup rather than be introduced at the same time as PHPStan itself.
- Should I fix findings or add them to the PHPStan baseline?
- Fix the real defects first: undefined variables, typos, and missing view data are genuine bugs that would otherwise only surface at runtime. Baseline only the findings caused by dynamic Blade constructs the analyser cannot resolve, and keep that baseline file small and commented so it stays reviewable. A noisy rule erodes trust in the whole PHPStan gate, so a tight baseline protects the value of the check.
- Is canvural/phpstan-blade-rule actively maintained, and what is the exit plan?
- It is a single-maintainer project with a low release cadence, which is acceptable for a dev-only quality tool but risky if it becomes a hard merge blocker. Pin the version, upgrade deliberately, and avoid enforcing it without an internal fallback. If releases stop, the exit plan is to pin and vendor the rule or drop the two config lines, since adoption is purely additive with no state or schema to roll back.