Parameter Name Guard Laravel Package

Technical Evaluation

Architecture fit. This package is a static-analysis rule that enforces naming conventions on function/method parameter names — for example, banning single-letter or ambiguous names. Architecturally it plugs into PHPStan (or a similar analyzer) as a custom rule and runs at CI/lint time, not at runtime. For a Laravel codebase it is purely a developer-tooling dependency: it sits beside larastan/phpstan, pint, and php-cs-fixer in the pre-merge pipeline and never enters the production artifact. It does not touch the framework container, routing, Eloquent, or HTTP layer, so it introduces no application architecture coupling.

Integration feasibility. Technically trivial: add the package as a require-dev dependency, register the rule class in phpstan.neon, and run. There is no service provider, config publishing, or bootstrap step. The practical blocker is not difficulty but status: the package is explicitly deprecated and archived, and the maintainer's own guidance is to replace it with PHP configs using constants with autocomplete. That means adopting it now is a deliberate, time-boxed decision, not a normal dependency add.

Technical risk. High relative to the value delivered, driven almost entirely by lifecycle concerns:

• No upstream fixes. Archived means no patches for new PHP minor versions, PHPStan major versions, or Laravel upgrades. A PHPStan upgrade that changes rule interfaces will silently break or hard-fail the rule, and nobody upstream will address it.
• Version drift. PHPStan's rule API and error-format APIs are not stable across majors; the rule is pinned to an era of PHPStan that may already be behind our baseline.
• Abandonment signal. 10 stars plus archived status plus an explicit deprecation notice is a strong prior that even fork-maintenance would be unowned work.
• Low blast radius if it fails. Because it is a dev-only lint rule, a break manifests as a CI failure to be removed or patched, not a production incident. This is the key mitigant: the downside is bounded.

Key questions.

1. What specific parameter-naming rule(s) do we actually need — is the requirement real, or is this solving a style preference that Pint/php-cs-fixer or an existing PHPStan rule already covers?
2. Does the rule function against our current PHPStan major version and PHP version, verified by a spike rather than assumed?
3. Is the naming convention a genuine team standard with a written rationale, or a one-off preference from a single contributor?
4. Who owns the rule if it breaks — do we fork and pin, or drop it?
5. Does the deprecation guidance ("PHP configs with constants autocomplete") map onto a problem we have in this Laravel codebase, or is that guidance aimed at Symplify's own config-heavy repos?

Integration Approach

Stack fit. Fits the standard Laravel static-analysis slot with no friction: require-dev, PHPStan rule registration, run in the same CI job as Larastan. It is compatible in principle with any Laravel version because it has no runtime footprint. The mismatch is philosophical rather than technical — it is a narrow, single-purpose rule packaged for a config-heavy ecosystem (Symplify's own tooling suite), and the deprecation note points toward a pattern (PHP configs with constants) that most Laravel applications do not use.

Migration path. Because this is greenfield tooling rather than a replacement for anything, "migration" is really adoption:

1. Spike first, in a branch. Install with --dev, register the rule, run against the existing codebase in report-only mode to measure violation volume. If the count is in the thousands, the convention is not de facto standard and enforcement becomes a cleanup project, not a lint addition.
2. Baseline or scope. If adopted, land it with a PHPStan baseline so existing violations are frozen and only new code is held to the rule. This is the standard low-friction route for new static rules.
3. Decide the enforcement level. Warning-level in CI first, error-level after the baseline proves stable.
4. Plan the exit. Record in the PR description that the package is archived and note the trigger conditions for removal (PHPStan major upgrade, PHP minor upgrade, or first unfixable break).

Compatibility. Verify against our pinned PHP and PHPStan versions before committing. Given archived status, treat any successful install as a point-in-time snapshot: pin the exact version in composer.json and commit composer.lock. Do not allow floating constraints on an archived dev dependency.

Sequencing. Low priority and non-blocking. It should not be sequenced ahead of anything in the quality pipeline; if the team has not yet standardized on PHPStan/Larastan, that is the prerequisite and this rule is a later, optional layer. Recommend: (a) confirm the naming requirement is real, (b) if yes, spike for one day, (c) adopt only if the spike passes cleanly against our versions.

Recommended posture. Default to not adopting. The deprecation notice is explicit and the maintainer has named a successor pattern. Reserve adoption for the case where a specific, documented naming standard exists and no first-party or actively maintained alternative (PHPStan's own rules, a small in-house rule, or a Pint/cs-fixer naming rule) covers it. Writing a ~50-line custom PHPStan rule in-house is a credible substitute that removes the abandonment risk entirely — and for a rule this small, that is often the better TPM recommendation.

Operational Impact

Maintenance. The dominant cost. An archived dev dependency is a standing liability: every PHP minor bump and every PHPStan major upgrade requires us to verify the rule still runs, and to patch or drop it ourselves if it does not. Because the rule is trivial in scope, the realistic long-term outcome is that we absorb it — vendor it into our own tooling repo or reimplement it — at which point the original package was only ever a starting reference. Budget a small but recurring maintenance line, not a one-time install.

Support. No upstream. No issue triage, no security patches (low relevance here — the package runs at lint time with no network or user input, so CVE exposure is minimal), no compatibility guarantees. Internal support burden falls to whichever engineer owns the static-analysis pipeline. Document the ownership explicitly; orphaned lint rules that fail confusingly are a common source of CI friction and developer distrust of the pipeline.

Scaling. Effectively unlimited. The rule operates per-file at analysis time; PHPStan handles parallelism and caching, and the marginal cost is negligible relative to the rest of the analysis run. On a large Laravel codebase the added wall-clock time will be unmeasurable next to Larastan itself. No scaling concern.

Failure modes. Ranked by likelihood:

• Silent no-op after a PHPStan upgrade — the rule stops being loaded or stops matching, and violations pass CI unnoticed. This is the most dangerous failure because it degrades quietly. Mitigate with a single deliberate canary test: a fixture file with a known bad parameter name that must fail analysis.
• Hard failure on upgrade — rule class references a removed PHPStan interface; CI blocks. Loud, therefore safe; resolvable by removing or patching.
• Developer friction — rule fires on legitimate short parameter names in narrow contexts (closures, $id, $e in catch blocks), causing workarounds and suppression comments. Tune the rule's allowlist before enabling at error level.
• Dependency resolution conflict — the archived package's PHPStan constraint pins us out of a needed PHPStan upgrade, forcing a premature drop.

Ramp-up. Near zero for engineers: they never interact with the package directly, only with the CI signal it produces. Onboarding cost is one paragraph in the contributor guide stating the parameter-naming convention and how to suppress a false positive. The real ramp-up cost is for the owner: understanding the rule's internals well enough to patch or replace it — a few hours, given the small surface area. That is affordable, which is why a in-house reimplementation is a reasonable alternative worth pricing in the recommendation.