Parameter Name Guard Laravel Package

Product Decisions This Supports

• API contract policy for named arguments. Since PHP 8, renaming a parameter in a public method is a semver-breaking change for any consumer using named arguments. This package is conceptually a guard for that surface. The product decision it informs: do we treat parameter names as part of our public API contract, and do we enforce that in CI?
• Build vs. buy. The "buy" path is closed — the package is [DEPRECATED], archived, and has 10 stars. The real decision is build: an equivalent check is a small custom PHPStan rule (roughly an engineer-day) with no external dependency risk.
• Roadmap input for SDK / library / shared-package work. If we ship anything consumed by other teams or external developers — an SDK, a public PHP library, a shared internal composer package — decide before GA whether parameter names are locked, because retrofitting that policy after adoption is a breaking change.
• Tech-debt prioritization, not feature roadmap. This delivers zero user-facing capability. Budget it as a quality gate / BC-break prevention line item, and do not let it compete with feature work.
• Dependency hygiene decisions. If it already exists in a legacy dependency tree, this assessment supports a removal ticket rather than a modernization ticket.

When to Consider This Package

• Effectively never for new adoption. It is explicitly deprecated and the repository is archived. No maintenance, no PHP-version compatibility guarantees, no security response, no upstream fixes. Star count and the Score: 0.025 signal confirm it has no meaningful community behind it.
• Only as inventory. If it already appears in a codebase we own, treat it as a removal candidate and replace it with a maintained rule or an in-house equivalent.
• Look elsewhere when you need an active quality gate. Use a maintained static-analysis ruleset, or write the rule ourselves — the check is narrow and well-scoped, which makes it a good fit for an in-house utility.
• Skip entirely if the codebase does not expose a public API (internal applications deployed atomically with all consumers). The named-argument backward-compatibility risk is negligible there, and the tooling cost is not justified.
• The deprecation note itself is a signal: the maintainers point users toward "PHP configs with constants autocomplete instead," meaning the upstream ecosystem considers this approach superseded. Adopting a superseded approach creates migration work later.

How to Pitch It (Stakeholders)

To executives: "This is a deprecated, archived open-source utility with 10 stars and no maintainer. We are not adopting it. The problem it addresses is real — on PHP 8, renaming a public parameter silently breaks downstream consumers — but the fix is cheap and we should own it rather than depend on abandoned code. Recommendation: no procurement, no license cost, no vendor relationship; one engineer-day to implement an equivalent static-analysis rule in-house, fully under our control. If it already exists in our stack, schedule removal."

To engineering: "The concept is worth keeping; this package is not. Named arguments make parameter names part of our public contract, so we should enforce that with a custom PHPStan rule in CI — approximately one day of work, no dependency risk, no abandoned code, and it can be tuned to our own semver policy. If symplify/parameter-name-guard is already in our tree, it should be removed and replaced in the same change so we don't lose the coverage."