Weave Code
Parameter Name Guard Laravel Package
symplify/parameter-name-guard
PHPStan extension that guards parameter names in public APIs, helping prevent backward-compatibility breaks with PHP 8 named arguments. It flags risky renames so library maintainers can keep signatures stable and safe.
[DEPRECATED] Use PHP configs with constants autocomplete instead
Frequently asked questions about Parameter Name Guard
- What does symplify/parameter-name-guard do?
- It is a PHPStan extension that guards parameter names in public APIs and flags risky renames. Because PHP 8 named arguments let callers pass values by parameter name, a rename is a backward-compatibility break even when types and order stay the same. The rule runs at static-analysis time in CI, not at runtime.
- Is symplify/parameter-name-guard deprecated?
- Yes. The package is explicitly marked deprecated and the repository is archived, with the maintainer recommending PHP configs with constants autocomplete instead. No upstream fixes should be expected for new PHP or PHPStan releases. Adopting it now is a deliberate, time-boxed decision rather than a normal dependency add.
- How do I install symplify/parameter-name-guard in a Laravel app?
- Add it as a dev dependency with composer require --dev symplify/parameter-name-guard, then register the rule class in phpstan.neon. There is no service provider, config publishing, or bootstrap step. Run it in the same CI job as Larastan.
- Does it work with Laravel and Larastan?
- In principle yes, because it is a PHPStan rule with no runtime footprint and no coupling to the container, routing, Eloquent, or the HTTP layer. Compatibility in practice depends on your PHPStan major matching the era the rule was built for. Verify with a short spike before committing rather than assuming.
- Why is renaming a parameter a backward-compatibility break?
- PHP 8 named arguments allow callers to reference parameter names directly at the call site, so renaming a parameter breaks those calls even if types and order are unchanged. Library and package maintainers must therefore treat parameter names as part of the public contract. The rule flags those risky renames so signatures stay stable.
- Does it add runtime overhead in production?
- No. It is a static-analysis rule that runs at CI and lint time and never enters the production artifact. It sits beside Larastan, Pint, and php-cs-fixer in the pre-merge pipeline.
- What PHPStan and PHP versions does it support?
- The rule is pinned to an older PHPStan era, and PHPStan's rule and error-format APIs are not stable across major versions. It may break silently or hard-fail after a PHPStan upgrade, and nobody upstream will patch it. Test against your current PHPStan major before adopting.
- How do I handle existing violations in a large codebase?
- Run it in report-only mode on a branch first to measure violation volume. If the count is in the thousands, the convention is not de facto standard and enforcement becomes a cleanup project rather than a lint addition. If adopted, land it with a PHPStan baseline so existing violations are frozen and only new code is held to the rule.
- What should I use instead of symplify/parameter-name-guard?
- The maintainer points to PHP configs with constants autocomplete, though that guidance targets Symplify's own config-heavy repositories. For parameter naming specifically, check whether Pint, php-cs-fixer, or an existing PHPStan rule already covers your requirement. If not, fork and pin the rule or write a small custom PHPStan rule.
- Who maintains the rule if it breaks on a PHPStan upgrade?
- Nobody upstream: the repository is archived and has roughly 10 stars, so a break becomes your team's fork-and-pin work or a removal. Decide ownership before adopting. The blast radius is bounded because a failure shows up as a CI failure, not a production incident.
Weaver
How can I help you explore Laravel packages today?