Blade Linter Laravel Package

Product Decisions This Supports

• Template quality gates in CI: A Blade linter gives the team an automated check on .blade.php formatting (e.g., sibling blank-line rules), so style consistency in views becomes enforceable rather than reviewer-dependent. This is the primary "build vs. buy" lever: adopt a small community linter instead of writing bespoke style checks.
• Roadmap item: standardize view conventions. If the roadmap includes a frontend/template style guide, this package is a cheap enforcement mechanism. The 0.3.1 fix (element directives treated as a boolean toggle) means the SiblingBlankLines rule behaves predictably around @if, @foreach, and similar directives — important if you plan to lint a large existing Blade codebase without a pile of false positives.
• CI reliability decision: The 0.3.1 change making the rule "safe for --no-dev installs" directly supports decisions about where the linter runs. It reduces the risk of lint steps failing in production-like or --no-dev CI images where dev dependencies are absent, which is a real operational concern for pipelines that reuse build images.
• Onboarding and review efficiency: Consistent Blade formatting lowers cognitive load in code review and speeds new engineers through template-heavy PRs. Useful input to decisions about PR checklists and Definition of Done.
• Build vs. buy / dependency posture: At 0.x, this is a low-cost, low-blast-radius dev dependency. Good candidate for a trial in a non-critical pipeline stage before deciding whether to standardize across repositories.

When to Consider This Package

Consider adoption when:

• You have a Laravel app (or several) with a meaningful volume of Blade templates and recurring formatting churn in reviews.
• You want a lightweight, single-purpose linter rather than a broad static-analysis suite, and can add it as a dev-only dependency.
• You are building or formalizing a template style guide and need automated enforcement.
• Your CI includes --no-dev stages and you want a lint rule that will not break there (the 0.3.1 fix is directly relevant).

Look elsewhere when:

• You need general PHP style/lint coverage — use established tools (e.g., Pint, PHP_CodeSniffer) alongside, not instead of, a Blade-specific linter.
• You need correctness checks on Blade compilation — view:cache/compile checks cover that; a linter addresses style, not semantics.
• Your organization requires a stable 1.0+ API, long-term support commitments, or a large maintainer base. At 0.x with a single-maintainer release cadence, treat it as a pilot, not a platform commitment.
• The rule set is too opinionated or insufficiently configurable for your conventions — validate on a sample of your templates before rollout.
• You cannot accommodate a niche, dev-only community dependency in your supply-chain policy.

How to Pitch It (Stakeholders)

Executives: This is a small, dev-only tooling addition that automates Blade template formatting. It reduces review time and enforces consistency in views at near-zero runtime cost and no production footprint. The latest patch (0.3.1) is a low-risk bugfix that improves rule correctness and CI safety; it does not change product behavior. Recommendation: approve a low-cost pilot in CI, revisit for broader standardization after a trial period.

Engineering: Single-purpose Blade linter, installs as a dev dependency and slots into existing CI/pre-commit hooks. 0.3.1 fixes SiblingBlankLines so element directives behave as a boolean toggle and the rule is safe under --no-dev installs — this removes a class of false positives and pipeline fragility. Caveats: it is 0.x, so pin versions and expect rule semantics to evolve; pair it with existing PHP linting rather than replacing it. Suggested next step: run against a representative template set, measure noise, then wire into the PR pipeline.