- How do I install beyondcode/laravel-prose-linter in a Laravel app?
- Install it as a dev dependency with composer require --dev beyondcode/laravel-prose-linter. Package auto-discovery registers the service provider, so no manual registration is needed. Publish the config with php artisan vendor:publish --tag=prose-config, then run php artisan prose:lint for a first report. Keep it in require-dev only, since it is a CI quality gate rather than an application capability.
- Which Laravel and PHP versions does laravel-prose-linter support?
- The latest release, v3.1.0 from February 2023, added Laravel 10 support and runs on PHP 8.1 or newer. No release after that exists, so Laravel 11 and 12 are not officially covered. Check the exact laravel/framework and php constraints declared in v3.1.0 before planning an upgrade path.
- How do I run the prose linter against my Blade views?
- Run php artisan prose:lint from your project root after installing the package. Scope the first run to a single directory, such as your customer-facing Blade views or lang catalogs, so the output stays readable. Starting narrow is the best way to judge signal quality before you widen coverage or wire it into CI.
- Can laravel-prose-linter fail a CI build on findings?
- The command is designed to be dropped into CI so copy review becomes an automatable signal, but verify its exit-code behaviour yourself before gating a pipeline on it. Test a deliberate failure on a scratch branch to confirm the contract. A common approach is a non-blocking report first, then a blocking step once the false-positive rate is understood.
- How do I configure which files and directories the prose linter checks?
- Configuration lives in config/prose.php, published with php artisan vendor:publish --tag=prose-config. That file controls paths, ignore semantics, dictionaries, and locale-related options, though you should confirm the depth of each against the source. Scoping the run to specific view directories is the single biggest lever on signal quality and noise.
- Does laravel-prose-linter work on Laravel 11 or Laravel 12?
- There is no official Laravel 11 or 12 support: the last release was v3.1.0 in February 2023 and its only note was adding Laravel 10 support. Composer resolution on newer framework versions is expected to fail. Making it work would require forking or vendoring the package and relaxing the constraints, which is an ownership decision rather than a config tweak.
- Is laravel-prose-linter still maintained?
- The repository is archived, the last release was in February 2023, and there is no listed maintainer, release cadence, or security disclosure path. Runtime risk is low because it is dev-only, MIT licensed, and ships no deployment artifact. Sustainability is the real risk, so assume you own any fixes and budget for a fork if you adopt it.
- Why does laravel-prose-linter report so many false positives on Blade and email templates?
- Blade directives, inline CSS in mail templates, and variable interpolation all produce text that a prose analyzer can misread as broken copy. How faithfully the parser strips @if, {{ }}, and @include determines both missed strings and spurious warnings. Tune ignores and domain terms early, because a noisy first run trains the team to ignore the output permanently.
- Does the prose linter send my copy to an external service?
- Confirm this before running it on any sensitive content: the package may be pure PHP or may shell out to an external binary or network service. If it delegates externally, your CI runner image needs that dependency and you take on version pinning. Verify that no application copy leaves the machine if your strings are confidential.
- What are good alternatives to laravel-prose-linter for proofreading Laravel copy?
- LanguageTool-based tooling, a vendor proofreading API, or an editor-side linter are the usual fallbacks when a package is unmaintained or too noisy. Most teams pair one of those with a maintained fork if they want to keep Blade-aware linting. Weigh them against your actual copy surface: if strings live in a JS-heavy frontend rather than Blade, a Blade-focused linter is the wrong tool.