Laravel Prose Linter Laravel Package

Technical Evaluation

Architecture fit. The package is a developer-only CI quality gate, not an application capability. It belongs in require-dev, never in a production image, and its only architectural surface is a service provider, a published config file (prose.php), and an Artisan command (php artisan prose:lint). For a TPM, the fit question is not "does this belong in our stack" but "do we have a copy surface worth gating" — customer-facing Blade views, mail/notification templates, and lang/ catalogs. Where copy is a visible product surface (UI strings, localized text, marketing-adjacent pages), it converts subjective copy review into an automatable signal that can be discussed in release-readiness terms rather than taste. It does not touch runtime, data model, queues, or deployment topology, so architectural blast radius is effectively zero.

Integration feasibility. Feasible and cheap on a Laravel 10 application (PHP 8.1+): composer dev dependency, package auto-discovery, vendor:publish --tag=prose-config, then a scoped run against a single directory. Two feasibility checks gate the estimate. First, the framework constraint: the only release note is "Add Laravel 10 support" (v3.1.0, 2023-02-16), so on Laravel 11/12 Composer resolution is expected to fail — that is a fork-or-vendor decision, not a config tweak. Second, whether the analyzer is pure PHP or shells out to an external binary (e.g. proselint/Python). If external, the CI runner image needs that dependency, and the "low-effort" estimate grows a Dockerfile change plus a version-pinning obligation. Confirm both before committing to a timeline.

Technical risk. Runtime risk is negligible (dev-only, MIT, no deploy artifact). Sustainability risk is the real risk: repository archived, last release 2023-02-16, 114 stars, 0 dependents, no maintainer, no stated cadence, no security disclosure path, unclear test coverage. The second-order risk is trust erosion from false positives — a noisy first run on minified assets, email templates with inline CSS, or vendor-adjacent views trains the team to ignore output, and once ignored the tool never recovers its value. The third is Blade parsing fidelity: how @if, {{ }}, and @include are stripped determines both missed copy and spurious warnings, and this is the main driver of signal quality. Secondary risks: no Laravel 11+ path without a fork, and potential external text transmission if the analyzer is not fully local (must be verified for any codebase with sensitive copy).

Key questions.

• What exact laravel/framework and PHP constraints does v3.1.0 declare, and does anything work on Laravel 11/12 unmodified?
• Is the analysis fully local, or does it call an external binary or network service? Is any application copy transmitted off-machine?
• What is the command's exit-code contract, path/ignore semantics, and changed-files support? Can it fail a build deliberately?
• How configurable are dictionaries, ignore lists, domain terms, and locale handling — and who owns tuning?
• What is the false-positive rate on our Blade and lang/ layout? What is the signal-to-noise baseline before we gate on it?
• Is there a maintained fork or credible replacement (LanguageTool-based tooling, vendor proofreading API, editor-side linter)?
• Which engineer and which content/localization owner are accountable for rule tuning and triage after the pilot?

Integration Approach

Stack fit. Best fit: Laravel 10 (or earlier) application using Composer and a real CI pipeline, with meaningful Blade/UI copy or translation catalogs and at least one non-English locale on the roadmap. Poor fit: Laravel 11+, a JS-heavy frontend where copy lives outside Blade, or a team without capacity to triage findings. Position it explicitly as dev tooling, not product scope — it should never appear as a release milestone or acceptance criterion.

Migration path. Run a time-boxed, single-branch trial with a written decision gate. Install under require-dev with an exact version pin, publish config, scope paths to one trusted directory first (--path=resources/views/marketing), then add lang/ because translation files are UI copy written by developers, reviewed by nobody, and shipped to every user. Baseline the findings before enabling anything in CI; tune ignore rules against real output; then add a single non-blocking CI step (continue-on-error) to measure noise over a sprint. Promote to blocking only on changed files once false positives are controlled. Because upstream is archived, the migration path has a terminal state: fork or replace before the next framework upgrade — decide which during the pilot, not after.

Compatibility. Verify: Composer constraints and PHP 8.1+, Laravel 10 support, auto-discovery under the app's discovery config, no conflict with existing dev dependencies, no database or runtime requirement, and CI runner compatibility (image, PHP extensions, any external binary). Treat the "Add Laravel 10 support" release as an upper bound, not a floor — do not infer Laravel 11+ compatibility from it. Also verify behavior against the app's actual Blade layout (components, slots, custom directives) since parsing fidelity is the main quality variable.

Sequencing.

1. Confirm framework/PHP versions and whether any external binary is required.
2. Install pinned version on a branch; publish config; clear caches; confirm the command registers.
3. Run against one trusted path, then lang/; baseline findings and count false positives.
4. Define ignore lists, domain-term dictionaries, and a named owner for tuning.
5. Add a non-blocking CI job; measure runtime and noise over ~2 sprints.
6. Enforce incrementally on changed files only.
7. Fork-or-replace decision before the next Laravel upgrade, with an exit date recorded.

Keep this as a dev-tooling workstream with its own owner, not a product release item.

Operational Impact

Maintenance. Upstream is archived: no bug fixes, no security patches, no new framework support. Runtime maintenance is zero, but ownership is not zero. Minimum viable maintenance posture: exact version pin, committed config, documented ignore-list rationale, and an org fork (trivial under MIT) if the tool proves valuable enough to keep. Record an explicit exit plan and review date so this does not silently become a permanent unmaintained dependency in the dev toolchain.

Support. No vendor SLA and no meaningful community depth (114 stars, 0 dependents). Expect no upstream responsiveness to issues. Assign an internal owner for configuration, dictionaries, CI failures, and escalation; that person is the de facto maintainer. Treat any framework upgrade as a scheduled re-evaluation of the dependency rather than an assumption of continued function.

Scaling. Scales with repository size and CI minutes, not application traffic — a favorable risk profile. Large Blade and translation catalogs will lengthen runs and multiply findings; scope scans to relevant directories or changed files, and cap runtime so the check cannot become a pipeline bottleneck. The more relevant scaling constraint is human: triage load grows with copy volume and locale count, so the ignore-list/dictionary investment should scale ahead of adding languages.

Failure modes. Composer resolution failure after a Laravel upgrade; command or config discovery failure (usually cache, not registration); false positives that block or annoy the pipeline; over-broad ignore lists quietly hiding real copy regressions; scanning generated, vendor, or compiled files; localization and domain-term false positives (product names, legal phrasing, brand voice); and — verify before use — unintended external transmission of copy. CI-only failures do not affect production, so the worst case is developer friction, not customer impact. The insidious failure is silent abandonment: the check stays green because everyone stopped reading it.

Ramp-up. Low for Laravel engineers (one dependency, one command). Low-to-medium for content, localization, and design owners, who must learn to interpret findings, tune rules, and arbitrate what counts as a false positive — this is where the ongoing cost concentrates and where a TPM should set expectations. TPM actions: fund a short pilot with a defined measurement (findings per 100 strings, false-positive rate, CI minutes), name an owner and reviewer, pin or fork on adoption, keep the gate non-blocking until signal quality is proven, and position the package publicly as a cheap tactical quality gate with a documented exit rather than a strategic platform commitment.