Phpstan Forbidden Laravel Package

Technical Evaluation

Architecture fit. PHPStan extensions hook into the analyzer as Composer require-dev packages registered through a phpstan.neon include, implementing PHPStan\Rules\Rule against the AST. This package adds no runtime dependency, no service provider, and no Laravel container coupling — so it slots cleanly into any PHP 8 project and coexists with Larastan. The architectural footprint is effectively zero in production; the only real coupling is to the PHPStan version and the shape of the configuration schema. That is the right kind of package for a TPM to greenlight at the "pilot" tier, because the blast radius of adoption is confined to CI.

Integration feasibility. Cheap, conditional on the team already running PHPStan in CI. If PHPStan is present, adoption is a composer require --dev, a neon include, and a ban list. There is no data migration, no schema change, and no deploy coordination. The practical work is not integration but content: deciding which entities to forbid and writing the rationale for each. That is a governance exercise, and it is where the real effort lives.

Technical risk. This is a high-risk dependency on paper despite the trivial install. Stars (7), dependents (0), score (14.37), and a single-author repo indicate an unproven package with a bus factor of one. The listed last release date of 2026-07-06 is anomalous and needs verification against the actual GitHub releases/tags before anything is pinned in a lockfile. The category is also crowded: spaze/phpstan-disallowed-calls is the mature, widely adopted incumbent and covers most of the same ground with better-documented configuration, rule identifiers, and baseline support. The core due-diligence question is not "does this work" but "does this do anything the incumbent doesn't." The opportunity score (54.13) suggests a genuine gap — likely ergonomics or a smaller config surface — but that is a hypothesis, not a finding, until the rule coverage is inspected.

Key questions.

• Which entity types are bannable — functions, static/instance methods, class instantiations, constants, namespaces, properties? Coverage gaps determine whether the incumbent is still required.
• Does each violation emit a stable rule identifier so it can be targeted in ignoreErrors and --generate-baseline? Without identifiers, baseline adoption is painful.
• Does it respect inline @phpstan-ignore / @phpstan-ignore-next-line suppression? Teams need an escape hatch with a paper trail.
• What is the supported PHPStan version matrix, and how quickly does it track PHPStan majors? A rule that breaks on a PHPStan upgrade blocks the whole analyzer upgrade.
• Are messages customizable, and can they carry a link to the ADR explaining why the entity is banned?
• What happens on an unrecognized config key — hard failure or silent no-op?
• License terms, and whether the maintainer is responsive to issues/PRs.

Integration Approach

Stack fit. Framework-agnostic by construction: PHP 8.x, PHPStan 1.x/2.x, optionally Larastan for Laravel-specific rules. It belongs in require-dev only. It is not a Laravel package in any meaningful sense and should not be evaluated as one — treat it as a PHPStan governance plugin that happens to be used by Laravel teams.

Migration path. There is no data or code migration; the migration is from convention to enforcement. The realistic paths are: (a) net-new adoption where no disallowed-call policy exists today; (b) migration from spaze/phpstan-disallowed-calls; or (c) coexistence, using this package for a narrow slice. Path (b) should be gated on rule-parity verification — if the incumbent already covers the ban list, there is no migration to justify. Path (c) is the most likely outcome and the lowest risk.

Compatibility. Pin the exact version, not a caret range. Verify PHPStan constraint against the team's current analyzer version before merging. Because the package is version-pinned to PHPStan internals, sequence its upgrades with PHPStan upgrades, never independently. If any repo is on a PHPStan major the package doesn't support, that repo runs without the rule rather than blocking on it.

Sequencing.

1. Read the source (it is small) and enumerate supported entity types and rule identifiers.
2. Benchmark against the incumbent on a single representative service — one afternoon, one branch.
3. If adopted: add to require-dev, wire the neon include, seed a minimal ban list drawn from existing ADRs and recurring code-review comments.
4. Run report-only in CI for one to two sprints to surface false positives.
5. Generate a baseline so existing violations don't block, then flip CI to blocking for new violations only.
6. Distribute as a shared phpstan.neon preset across repos so the policy is centralized rather than copy-pasted.
7. Stand up a lightweight review process for adding bans — one owner, a written rationale per entry, no drive-by additions.

Operational Impact

Maintenance. Small code surface means low churn, but also low maintenance capacity. The realistic risk is not that the package breaks often; it is that it stops tracking PHPStan and becomes the reason an upgrade stalls. Mitigation: budget for a fork/vendor contingency, and keep the ban list in your own config so a package swap is a one-line include change rather than a rewrite.

Support. No commercial support, no SLA. Internal ownership must be explicit — assign a named owner (typically a platform or developer-experience engineer) who watches upstream issues and PHPStan release notes. Without that assignment the rule silently decays.

Scaling. Per-rule AST traversal overhead is negligible relative to the rest of a PHPStan run; the analyzer's own cost dominates. The scaling story is organizational, not computational: a shared preset means one policy change propagates to every repo in one PR, and a growing ban list becomes a living record of architectural decisions. Roll out repo-by-repo, not org-wide on day one.

Failure modes.

• Silent no-op — a typo'd or restructured config key causes the rule to register but match nothing. This is the worst outcome because CI stays green while governance is fiction. Guard with a canary test: deliberately ban a function you know exists in a fixture and assert the rule fires.
• False positives blocking CI on legitimate usage, especially around framework magic and __call/__callStatic dynamic dispatch.
• Crashes on unhandled node types, taking down the entire analysis run rather than just this rule.
• Abandonment — the maintainer stops publishing and a PHPStan major leaves the package stranded.
• Baseline drift — if identifiers are unstable, regenerated baselines churn and review noise erodes trust.

Ramp-up. Developer ramp-up is genuinely low — under an hour to install and configure. Team ramp-up is the real cost: every banned entity needs a documented reason and an approved alternative, or engineers will route around the rule with inline suppressions. Treat the ban list as documentation, not as a bludgeon. A 7-star package with zero dependents is reasonable to pilot in one service with a pinned version and an exit plan; it is not reasonable to make a mandatory org-wide standard without first proving it beats the incumbent on something concrete.