Phpstan Error Formatter Laravel Package

Product Decisions This Supports

• Static-analysis adoption roadmap. If there's a roadmap item like "raise PHPStan to level 8 on Laravel/Larastan" or "make static analysis a blocking CI gate," this package is the change-management lever for it. It doesn't make analysis better; it makes the output of analysis cheaper to read, which is usually what stalls level upgrades in practice.
• Build vs. buy (buy = adopt). Teams routinely hand-roll output post-processors, log scrapers, or IDE plugins to make PHPStan legible. This replaces that with one dev dependency plus two config lines (errorFormat: ticketswap, editorUrl), MIT-licensed, removable in a single revert. Low-cost, low-regret decision — the kind that can be made by a tech lead without a PM sign-off.
• Developer-experience investment portfolio. Sits in the same bucket as Prettier, editorconfig, or PHP-CS-Fixer: no customer-facing value, measurable only indirectly via time-to-fix, PR cycle time, and onboarding ramp. Good candidate for a small, timeboxed DX experiment with a before/after measurement rather than a business case.
• AI-assisted development workflows. Release 1.3.0 explicitly stops truncating file paths when it detects an AI agent. That's a concrete signal the maintainer is tracking coding-agent toolchains — relevant if your roadmap includes agent-driven refactors where errors must remain machine-traceable back to a file and line.
• Toolchain standardization across teams or vendors. Useful when multiple teams, contractors, or agencies share a codebase and you want a single, opinionated error format instead of per-team scripts. Caveat: with 0 dependents on record, you are effectively an early adopter, not part of a crowd.
• Decisions this should not drive: anything customer-facing, performance, security, or compliance. This package only renders errors; it has no effect on what PHPStan finds, and therefore must never be used as justification for lowering or raising analysis strictness.

When to Consider This Package

Adopt when:

• PHPStan (typically via Larastan) is already in CI or in pre-commit hooks, and PHP is 8.1+.
• The blocking complaint about static analysis is legibility — wrapped tables, file/line references that require manual navigation, junior developers or contractors bouncing off the output.
• Developers work in terminals with clickable-link support (VS Code, iTerm2, most modern terminals) or you can set editorUrl. Where links aren't supported, the fallback is a printed file:///... path, not a broken build.
• You're running a level-up or ruleset-tightening initiative and want to reduce the perceived tax of the new errors during the transition.
• Your pipeline consumes human-readable output only. It also degrades sensibly when output isn't decorated (tips and identifiers are still printed).

Look elsewhere when:

• You don't use PHPStan — Psalm, Pest, PHP-CS-Fixer, or a custom linter have no path to this package.
• You need machine-consumable output. For CI integrations, PHPStan's own --error-format=json/github/gitlab/teamcity formatters are the right tool; this is a human formatter and should not be wired into anything that parses text.
• You need error enrichment beyond presentation — JIRA ticket links, Slack notifications, severity routing, custom grouping. None of that is in scope.
• Your organization requires vendor-backed or widely adopted dependencies. Signals here are thin: ~87 stars, 0 recorded dependents, a small maintainer group, and a history of single-maintainer-driven releases. The mitigation is that the blast radius of removal is near zero, but that's a risk-acceptance decision, not an argument that it's widely proven.
• You run mixed or unusual shell/terminal environments (Windows support landed in 1.2.5; treat it as validated-by-CI rather than broadly field-tested) and can't tolerate cosmetic degradation.

How to Pitch It (Stakeholders)

Executives (one paragraph): "We're proposing a zero-cost developer-productivity change: a small MIT-licensed open-source add-on that reformats PHPStan's static-analysis output so every error is a clickable file-and-line link with syntax highlighting. It's a dev-only dependency with a one-line install and a one-line revert, no licensing cost, no runtime or customer impact, and no effect on what our analyzer flags. The expected return is faster triage of static-analysis failures and less onboarding friction for engineers new to our quality gates. Because it's cheap and reversible, we recommend a two-week trial on one team with a simple before/after measure of time-to-fix rather than a formal business case."

Engineering: "It's presentation only. composer require --dev ticketswap/phpstan-error-formatter, then errorFormat: ticketswap; with phpstan/extension-installer nothing else is needed, otherwise include extension.neon. Set editorUrl (phpstorm://open?file=%%file%%&line=%%line%% or vscode://file/%%file%%:%%line%%) — the formatter depends on it for clickable links. Works with Larastan and PHPStan 2.x; CI covers PHP 8.1–8.5. It's active but small — pin the version, don't build automation on its text output, and assume we may remove it later at no cost. Do not use it where CI needs structured errors; keep the JSON formatter there."

Ask: a timeboxed trial on one team or repo, success criteria = reduced time from phpstan analyse failure to opened file for a sample of real errors, plus no CI regressions. Revert cost is one commit, so the downside is bounded regardless of outcome.