Parameter Name Guard Laravel Package

Getting Started

Before anything else: this package is archived and marked deprecated by its author. Treat any installation as a short-term stopgap, not a foundation. The deprecation note ("Use PHP configs with constants autocomplete instead") is the intended migration path — read it as the actual recommendation for new code.

If you still need it on an older Symfony/PHPStan stack:

1. composer require --dev symplify/parameter-name-guard on a project pinned to a PHPStan version the package supports (check composer.json constraints — this is the first thing to verify, not the README).
2. Register the shipped rule in phpstan.neon rather than relying on auto-discovery:

   includes:
       - vendor/symplify/parameter-name-guard/config/config.neon
   

   (or register the rule class manually under services: — check the package's config/config.neon for the exact rule name in your installed version, since it differs across releases.)
3. Run vendor/bin/phpstan analyse and confirm the rule actually fires by deliberately introducing a misspelled parameter name in a service definition.
4. First use case: wire it into the same PHPStan run you already have in CI, so typo'd %parameter.name% string references fail the build instead of surfacing as a ParameterNotFoundException at container compile or, worse, at runtime.

Where to look first inside the repo: the single rule class under src/ and its config/ directory. The package is small — the rule plus its config is the whole product.

Implementation Patterns

• Layer it on the existing static-analysis stage. Do not create a separate CI job. The rule's value comes from being part of the phpstan analyse run developers already run locally and in CI, so a typo is caught in the same feedback loop as a type error.
• Generate a baseline for legacy codebases. On a brownfield app, the first run will light up every existing inconsistency. Use phpstan --generate-baseline, commit the baseline, and prevent new violations while paying down the old ones incrementally.
• Pair with Symfony's own container checks. bin/console lint:container and debug:container --parameters validate the compiled container; this static rule catches problems earlier and without a boot. Use both, but understand they overlap — the static rule is the fast gate, the console lint is the authoritative one.
• Keep it scoped to config and service-definition paths via paths: in phpstan.neon, so it doesn't run against test fixtures or vendored code where parameter strings are intentionally fake.
• Migration pattern (the recommended one): move YAML/XML service definitions to PHP config files and reference parameters through class constants or typed accessors. That gives you IDE autocomplete and compile-time safety without a bespoke PHPStan rule — which is precisely why the author deprecated this package. If you're on a recent Symfony, this is the day-one plan, and the guard package is at most a bridge for the parts you haven't migrated yet.
• Treat the rule as documentation. When a teammate asks "why did CI fail on a string?", the rule's message is the answer. Add a short note in your contributing docs pointing to it so the failure isn't mistaken for a flaky build.

Gotchas and Tips

• PHPStan API drift is the dominant risk. PHPStan's rule interfaces and node-resolution helpers change across major versions. An archived package cannot track those changes, so the realistic failure modes are a rule that silently stops being registered, a fatal Class not found on a newer PHPStan, or — worst — a rule that loads but no longer resolves the nodes it inspects and therefore detects nothing. Verify the rule fires after any PHPStan upgrade; a green build is not proof it's working.
• Silent no-ops are the real danger. Any static-analysis rule that produces zero findings is indistinguishable from a rule that isn't running. Add one intentionally broken fixture in a test file that is expected to fail, or you'll lose coverage without noticing.
• Pin the PHPStan version in composer.json for as long as you depend on this package. Floating ^1.x/^2.x constraints will eventually resolve to a version the archived rule doesn't support.
• Rule registration is the usual config quirk. includes: vs. manual services: registration produce different behaviour when only some rules are registered; check config/config.neon in the installed version rather than copying snippets from the README, which may not match your tag.
• Suppress narrowly, not globally. Use ignoreErrors with path:/message: scoping for the handful of genuinely dynamic parameter references; a blanket reportUnmatchedIgnoredErrors: false or a wide ignore pattern hides real typos.
• Don't fork it unless you must. The scope is one rule. If you need it to survive, a ~100-line custom rule in your own repo (or a locally vendored copy under your own namespace) is cheaper to maintain long-term than adopting dead code with an external issue tracker. That is also the cleanest extension point: reimplement the check against your current PHPStan version.
• Check for a maintained successor before writing anything. Symfony's lint:container, PHPStan's Symfony extension, and the PHP-config-plus-constants approach collectively cover most of what this package did. If any of them are already in your stack, you likely don't need this at all.
• Composer hygiene: with a 10-star, archived, MIT package, composer audit won't flag it as insecure — archiving isn't a CVE. Track it manually in your dependency review so it doesn't sit in require-dev for years unnoticed.