Laravel Blade Lint Laravel Package

Product Decisions This Supports

• Build vs. buy for template-level CI checks. Blade templates are only compiled when a view is first rendered, so a syntax error in a rarely-hit page (password reset email, 500 error page, admin-only screen, invoice PDF) can pass code review, pass PHPUnit, pass static analysis, and still ship to production as a runtime 500. This package addresses a genuine blind spot in the default Laravel quality stack at near-zero integration cost — the "buy" case is strong precisely because building and maintaining this yourself is a distraction, not a differentiator.
• Release-confidence / quality-gate roadmap decisions. Adopting it enables a pre-merge gate that is cheap enough to run on every push, which shifts defect discovery left for a class of bug that is otherwise found by users. Relevant if you are weighing investment in CI hardening versus more end-to-end/browser test coverage (which is orders of magnitude slower per view covered).
• Coverage-gap triage. Use it as an argument in prioritization: if your test suite renders only a fraction of your templates, a lint pass over all templates buys breadth that your test suite cannot afford. This can defer or de-scope a "raise view test coverage" initiative in favor of a cheaper, narrower control.
• Incident-prevention use cases worth naming in the business case: orphaned/abandoned views referencing deleted components, merge-conflict residue in templates, package upgrades that change Blade directive syntax, and large multi-team repos where a template owned by Team A breaks a layout owned by Team B.
• Scope boundary decision. It is a syntax/compile check, not a correctness check. Adopting it should be explicitly framed as complementary to — not a substitute for — PHPStan/Larastan and rendered-output tests, so nobody books it as "template testing solved."

When to Consider This Package

Adopt when:

• You run a Laravel app with a meaningful number of Blade templates and no existing template lint step in CI.
• Your CI budget or pipeline latency rules out rendering every view (Dusk/Pest browser tests) on each PR.
• You want per-file, isolated error reporting without mutating the compiled view cache — php artisan view:cache will catch compile errors today, but it compiles everything into the cache as a side effect and gives coarser failure output. If that is already good enough for you, this package's marginal value is small and you should say so internally.
• The package is installed as a require-dev dependency with a pinned version, and has been reviewed for what it executes in your build environment.

Look elsewhere or hold when:

• Licensing is a real gate. GPL-3.0 is copyleft and unusual for the Laravel ecosystem, which is overwhelmingly MIT. Dev-only usage inside your own CI is usually tolerable, but if you distribute the application (on-prem, appliance, white-label, or a customer-hosted product), get legal sign-off before it lands in composer.json. If legal says no, view:cache in CI is your fallback.
• Supply-chain / maintenance risk is material. 16 stars, an unattributed repository, and a single-maintainer profile mean bus-factor and provenance risk. Adding it to CI grants its code execution in your build. Require a source review, a commit hash or exact version pin, and a named owner who re-evaluates it each Laravel major upgrade.
• You already have mature coverage. If every view is exercised by feature tests or snapshot tests, this is redundant tooling that adds a dependency for near-zero marginal defect capture.
• You need semantic checks. Undefined variables, wrong component props, missing translations, or broken asset references are out of scope — reach for Larastan plus targeted rendering tests instead.

How to Pitch It (Stakeholders)

To executives (one paragraph): A small, low-cost addition to our CI pipeline that closes a specific reliability gap: Laravel page templates are only validated when a user actually loads the page, so a broken template in a low-traffic or admin-only screen can reach production undetected and surface as a hard error in front of a customer. This tool checks every template before merge in seconds. It is a development-only dependency with no production runtime footprint, no performance impact, and no architectural commitment — we can remove it in one line. The one caveat is its GPL-3.0 license, which we need legal to clear before it enters the build, and its small maintainer base, which we mitigate by pinning the version and reviewing the source. Recommended as a low-risk quality-gate add, contingent on legal sign-off.

To engineering (short): Adds a single artisan lint command over all Blade templates suitable for a per-PR CI step — fast, isolated per-file failures, doesn't touch the compiled view cache. Complementary to Larastan, not a replacement for rendering tests. Install as require-dev, pin it, and vendor the source review because it runs inside CI. If the GPL license blocks us, php artisan view:cache is the zero-dependency substitute, with worse ergonomics and a cache side effect.