Phpstan Php Parser Laravel Package

Product Decisions This Supports

• Developer-tooling roadmap, not customer-facing features. This package only matters if the team ships code that parses or rewrites PHP with nikic/php-parser (codemods, migration scripts, custom lint rules, refactoring bots, static-analysis extensions). If that work is on the roadmap, it supports a decision to invest in typed, CI-checked AST tooling instead of untyped one-off scripts.
• Build vs. buy for internal analysis tooling. The "buy" option is a 23-star, archived, seven-year-stale extension. That is effectively a build decision: vendor it, pin it, or replace it with in-house stubs. The package's existence is evidence the integration is a known, small, solvable problem — not a reason to depend on it.
• Quality-gate scope. If adopted, it lets PHPStan catch type errors inside custom PHPStan rules and codemod packages that manipulate Node, NodeVisitor, and NodeTraverser objects — a class of bugs that unit tests routinely miss.
• Risk-tiering of the dependency inventory. Low stars plus archived status is a weak-signal, high-abandonment dependency. It belongs in the "tolerated, owned internally, not strategic" bucket — a useful input for dependency-governance and supply-chain decisions.
• Use cases this maps to: pre-commit/CI type checks on internal refactoring tooling; onboarding engineers who write AST visitors; reducing runtime failures in migration scripts that run against production codebases.

When to Consider This Package

Consider it only when all of the following hold:

• The project already depends on both phpstan/phpstan and nikic/php-parser, and the team wants static analysis to cover its AST-manipulating code.
• The Laravel/PHP version and PHPStan major version line up with the 2021-era compatibility window (roughly PHP 7.x–8.0 and PHPStan 0.12/1.x). Verify against the lockfile before planning anything.
• The scope is internal tooling where a broken analysis run is an annoyance, not an outage.

Look elsewhere when:

• Greenfield or actively upgraded stacks. Modern PHPStan releases and the wider extension ecosystem cover much of this ground; a stale extension is more likely to conflict than help.
• The team does not manipulate PHP ASTs. Zero value, non-trivial dependency surface.
• Supply-chain or audit requirements apply. Archived, unmaintained, single maintainer, no security response path.
• You need a supported vendor relationship. There is none here. If the capability is genuinely needed, budget engineer time to fork it under an internal namespace or write the handful of stub declarations directly.

How to Pitch It (Stakeholders)

For executives: This is a small, free developer-productivity add-on for static analysis of internal PHP tooling. It carries no license cost and no customer-facing impact. Its weakness is stewardship — it is archived and effectively frozen — so treat any use as an internal maintenance commitment, not a vendor dependency. Recommended position: do not add it to the roadmap as an initiative; let engineering decide at the team level, with a named owner if it stays.

For engineering: Treat this as a dev-only dependency with an expiration date. If it is already in the lockfile and CI is green, leave it and pin the version. Do not introduce it into new projects. Before the next PHPStan or PHP major upgrade, run a short spike to replace it with either built-in stubs or ~a day of in-repo type declarations. Do not let it become load-bearing without an owner, and do not count on upstream fixes — there is no active maintainer.