rector/phpstan-rules
PHPStan rules for Rector projects that catch common mistakes in Rector rules and configuration, helping you keep automated refactorings safer and more consistent. Use these ready-made checks to validate custom rules and configs before they rewrite your codebase. Ideal for teams maintaining custom Re...
Architecture fit. rector/phpstan-rules is a PHPStan extension, not an application library. It plugs into the static-analysis layer of a PHP codebase and encodes conventions specific to Rector’s internal design patterns—particularly static reflection and Rector rule authoring. That makes it a good architectural fit only for repositories that build or maintain Rector rules, Rector extensions, or Rector-adjacent tooling. For a conventional Laravel product codebase, the rules target the wrong domain: they enforce how Rector rules should be written, not how Laravel controllers, models, or services should be written. The package should be viewed as developer-tooling infrastructure, not a runtime dependency.
Integration feasibility. Technically straightforward to install as a require-dev Composer package and register as a PHPStan extension. Most Laravel teams already run PHPStan through Larastan, so the host tooling exists. The real feasibility question is whether the rules have anything to analyze. If rector/rector is absent, some rules may be irrelevant or may fail to resolve Rector types. Integration is therefore high-effort-to-value unless the team is actively authoring Rector rules and wants static enforcement of Rector’s own conventions.
Technical risk. High relative to value. The package has no visible dependents, no star signal, and a zero score in the supplied metadata, which suggests either an internal-only package or very early/limited publication. Risks include: tight coupling to specific PHPStan and Rector versions; PHPStan extension API changes between major versions; opinionated rules producing noisy false positives if applied broadly; and abandonment or irregular release cadence. Because the package is small and narrowly scoped, breakage is easy to work around by pinning or vendoring rules, but that also means ongoing ownership shifts to the adopting team.
Key questions.
rector/rector at analysis time, or only target Rector-shaped code?Stack fit. Poor fit for Laravel application code; reasonable fit for an internal tooling repository that contains custom Rector rules or Rector extensions. If the organization already standardizes on PHPStan/Larastan in CI, the marginal infrastructure cost is low, but the rules should not be enabled globally. They belong in a narrow PHPStan configuration scoped to the directories where Rector rule code lives.
Migration path. Treat this as a pilot, not a rollout. Add it as a dev dependency in a branch, register the extension in a dedicated phpstan-tooling.neon config, and point it at a single directory. Run PHPStan with a baseline to quantify noise. If the rules produce actionable findings on Rector rule code, keep the scoped config; if they produce mostly irrelevant or duplicate findings, remove the dependency. There is no meaningful migration path for product code because the rules do not model product-code concerns.
Compatibility. Verify PHP version constraints, PHPStan major version, extension-installer support, and Rector version alignment before committing. Because the package is tightly coupled to Rector internals, pin the exact version in composer.json and avoid floating constraints. Check whether the rules rely on Rector classes being autoloadable during analysis; if so, rector/rector must be present in the same dependency set. Validate in CI on the lowest and highest supported PHP/PHPStan combinations.
Sequencing.
Maintenance. Low runtime footprint, but non-zero ownership. The package adds a dev dependency that must track PHPStan and Rector upgrades. With no dependents and no visible community pressure, the adopting team effectively owns compatibility. Pinning versions and scoping the config keeps maintenance bounded; vendoring the few useful rules is a viable exit strategy if the package stalls.
Support. Expect best-effort support from the Rector maintainers, not a product SLA. Issues may be addressed as part of Rector’s own priorities. Internal documentation should record why the package is present, which rules are enabled, and who owns upgrades. Without that, it becomes orphaned tooling that silently breaks CI during PHPStan upgrades.
Scaling. Analysis cost is negligible; the ruleset is small and scoped. The real scaling constraint is organizational: the package is useful to a small number of engineers who write Rector rules, and provides little value to the broader engineering organization. It should not be positioned as an enterprise-wide static-analysis standard.
Failure modes.
Ramp-up. Near-zero for general application developers because the rules are irrelevant to their work. Moderate for engineers authoring Rector rules: they need to understand Rector’s static reflection APIs, PHPStan custom-rule mechanics, and the conventions being enforced. Budget a short spike and a written internal note rather than formal training.
TPM recommendation. Do not adopt for general Laravel product code. Evaluate only if the team is actively building custom Rector rules or contributing to the Rector ecosystem, and then adopt in a path-scoped, version-pinned configuration with a clear owner and a vendoring fallback. The low opportunity score and zero dependents are consistent with a niche internal-tooling package rather than a platform dependency.
How can I help you explore Laravel packages today?