Laravel Prose Linter Laravel Package

Product Decisions This Supports

• Whether copy quality is a managed product property or an accident of who edits last. This package turns user-facing text — emails, notifications, Blade views, translation strings — into a testable assertion. That reframes a subjective argument ("this reads badly") into a binary signal a team can act on, and forces a PM to state a quality bar explicitly rather than inherit one.
• A copy review process decision, not a tooling decision. The real choice on the table is manual review vs. automated gate vs. nothing. Manual review doesn't scale past a handful of strings per release; "nothing" is the current de facto state for most teams. This package makes the middle option cheap enough to actually try, which is the decision worth bringing to a roadmap conversation.
• Localization readiness and expansion sequencing. If adding a locale is on the roadmap, string quality becomes a launch gate per market. Linting lang/ files is a low-cost pre-check that catches drift, inconsistent capitalization, and leftover developer phrasing before a translator or a customer sees it. This informs when localization is safe to commit to, and whether the team needs a review step before it.
• Release gating policy — a PM-owned call. CI returns a non-zero exit when prose regresses. Someone has to decide whether a stray double space fails a deploy. That is a product judgment about what "done" means, not an engineering default, and it should be made deliberately and written down.
• Build vs. buy for non-differentiating quality tooling. Nobody wins a market by owning a prose linter. The default should be adoption over construction — with the caveat that this specific package is archived (last release 2023-02-16, Laravel 10 only, 114 stars, 0 dependents). So the decision isn't "adopt a tool," it's "tactically adopt a small MIT tool we could vendor or fork, with a named exit date," versus "wait for a maintained alternative."
• Sequencing against framework upgrades. Because the package stops at Laravel 10, it collides with any planned Laravel 11/12 upgrade. That makes it a scheduling input: either the copy-quality experiment happens before the upgrade, or it starts as a fork.
• Whether in-app copy doubles as documentation. For products where UI text carries the explanatory load, this is an early-warning system for docs drift — and a reason to decide between investing in copy consistency and accepting it.

When to Consider This Package

Worth a pilot when:

• You're on Laravel 10 or earlier, so the dependency resolves without a fork.
• Copy is a visible product surface — customer emails, notifications, localized strings — and manual review is inconsistent or nobody owns it.
• You want a cheap, time-boxed experiment: one dev dependency, one Artisan command, one non-blocking CI step. Cost of finding out is hours, not a quarter.
• You can name an internal owner for rule tuning, ignore lists, and false-positive triage before you start.
• You're comfortable with dev-only tooling that never ships to production, where the blast radius of abandonment is limited to a broken CI step.

Look elsewhere or defer when:

• You're on Laravel 11+. An archived repo pinned at a Laravel 10 release will not track the framework. Fork or skip.
• You need a support window, security disclosure path, or release cadence. Zero dependents and an archived upstream mean no vendor accountability for anything load-bearing.
• The copy is non-English or requires genuine grammatical analysis. "Syntax-aware proofreading" is not a grammar engine — validate recall and precision on your actual strings before promising anything.
• You'd be blocking deploys on it. Don't gate releases on best-effort, unmaintained heuristics.
• You want a platform commitment. This is a tactic with a shelf life, not infrastructure.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed developer tool that automatically checks the quality of user-facing text and translations in our Laravel app and can run as a CI step. The business case is modest and concrete: less manual copy-editing, more consistent UI and localized copy, and one fewer class of embarrassing defect reaching customers. The material caveat is lifecycle: the package is archived, last updated for Laravel 10, with no maintainer. That makes it a tactical experiment, not a platform bet — it's dev-only tooling that never runs in production, it's cheap to fork or replace, and we can pilot it in a single pipeline before any broader commitment. Recommendation: approve a short pilot with a named owner, pin the version, keep the check non-blocking, and agree up front on the date we either fork it or move on.

For engineering: Treat this as a quality gate for authoring, not application functionality. Install under require-dev, publish the config, scope it to specific directories — start with one marketing view or one lang/ directory you trust so the first run is clean, then widen. Baseline existing findings, tune ignores for email templates, generated files, and domain terms, then add one non-blocking CI job and measure noise before promoting it to blocking on changed files only. Be explicit about the risks: upstream is archived, v3.1.0 targets Laravel 10, there's no maintainer, and compatibility with newer frameworks is unproven. Verify PHP/Laravel constraints, confirm whether it shells out to an external binary (a classic local-passes/CI-fails trap), and check behavior against our actual Blade and lang/ layout. Pin the exact version, name an owner, and document the fork-or-replace decision point before this becomes habit.