Phpstan Composer Analysis Laravel Package

Product Decisions This Supports

• Toolchain consolidation vs. tool sprawl. The core decision this informs is whether to add dependency analysis as a separate CI step (running shipmonk/composer-dependency-analyser directly, or composer-unused / composer-require-checker) or to fold it into the PHPStan run the team already has. This package exists specifically to make the second option cheap.
• Build vs. buy vs. adopt. Strongly "adopt." The wrapper is thin; there is no product justification for internalising this capability.
• Quality-gate roadmap. Useful input to any "shift checks left / reduce CI job count / standardise failure formats" initiative — it trades a new pipeline stage for an existing one.
• Dependency-pruning and upgrade work. Surfaces unused, shadowed (declared in require but only used in dev, or vice versa), and undeclared transitive dependencies as PHPStan errors. That directly supports decisions like "can we drop this package," "is this a real dependency or an accident of the autoloader," and "will this composer update break a deploy because we relied on something we never declared."
• Monorepo / package-split decisions. Misplaced-dependency findings are the evidence base for deciding what belongs in a library's require vs require-dev before extraction.
• Risk acceptance decisions. Adopting means taking a 17-star, single-maintainer wrapper into the build path; that is a discrete, recordable decision, not an accident.

When to Consider This Package

Consider it when:

• PHPStan is already a required CI gate and you want dependency hygiene inside it — no new job, no new config file format, no second failure-report parser.
• You want dependency findings to inherit PHPStan behaviour you already rely on: baselines, ignore-errors, error identifiers, exit codes, IDE/editor surfacing, and the same PR annotations.
• The team is small enough that a second suppression mechanism and a second CI artefact is genuine friction.
• You are comfortable with the upstream analyser doing the actual work and this package being a thin adapter.

Look elsewhere when:

• PHPStan is not in use — run shipmonk/composer-dependency-analyser directly; the wrapper adds nothing.
• You need enforcement at install time rather than in CI (composer-require-checker in a Composer script, or a Composer plugin).
• You need vendor support, an SLA, or an org-backed maintainer. Seventeen stars and a single maintainer is a real supply-chain and bus-factor consideration; if that fails your dependency policy, call the analyser binary directly and accept the extra CI step.
• You need rule-level customisation the wrapper does not expose — go to the analyser's own API.
• Your PHPStan run is already near its time budget; dependency analysis may belong in a nightly job rather than on every push.

How to Pitch It (Stakeholders)

For executives: This adds a check that the dependencies we declare in Composer match the ones our code actually uses, and it runs inside the code-quality tool we already have in CI. Cost is roughly half a day of setup and a near-zero ongoing pipeline cost; the payoff is eliminating a recurring class of production breakage where a routine composer update removes something we were silently relying on.

For engineering: It is a thin PHPStan extension around shipmonk/composer-dependency-analyser. You register it once in phpstan.neon; unused, shadow, and misplaced dependencies then appear as ordinary PHPStan errors, suppressible through the baseline we already maintain and visible in editors and PR annotations. No new CI job, no new output format, no new suppression file. The trade-off is a small third-party dependency with a single maintainer — if that is unacceptable, the fallback is invoking the analyser's binary as its own CI step, which costs one more job and a second ignore-list. Success looks like: dependency issues caught in the first month, no measurable CI time regression, and zero new pipeline configuration to maintain.