Phpmd Shim Laravel Package

Product Decisions This Supports

• Code quality gating in CI pipelines: PHPMD (PHP Mess Detector) is a static analysis tool for PHP that surfaces code smells, cyclomatic complexity, unused code, and naming issues. Whether or not this shim is the delivery mechanism, a PM decision to enforce quality gates depends on a reliable PHPMD installation — so the shim is a tactical dependency that either enables or blocks that gate.
• Standardizing static analysis across internal PHP services: If multiple teams need a consistent PHPMD version in a Composer-based monorepo or across legacy services, a shim can resolve version-constraint conflicts that block a uniform config. That's a portfolio-level tooling decision, not a feature decision.
• Build vs. buy (shim vs. upstream): The core PM question is whether to depend on an internal 0-star shim with 0 dependents, or pin upstream phpmd/phpmd directly and manage the constraint conflict at the project level. Unless there's a specific Composer resolution problem this shim uniquely solves, upstream is the lower-risk answer.
• Supply-chain and maintenance risk on the roadmap: A shim is an extra hop in the dependency graph — it sits between your projects and a maintained upstream tool. If it goes stale, every project depending on it inherits that staleness. This should be tracked as a technical debt item with a review cadence and an owner.
• Deprecation/consolidation decision: Given negligible adoption, this is a candidate for retirement in favor of direct upstream use or a replacement tool (PHPStan, Psalm, or upstream PHPMD). PM should decide the exit criteria explicitly rather than let it linger.

When to Consider This Package

Consider it only when:

• Your team already standardizes on PHPMD for static analysis and needs the specific pinned version range that this shim enables — i.e., upstream PHPMD's Composer constraints conflict with your project's constraints and the shim is the least-bad resolution.
• You are inside the IRSTEA environment or an organization with direct access to this GitLab host and an existing internal relationship with the maintainers.
• The adoption is time-boxed and scoped — one team, one pipeline, an explicit plan to migrate off.
• You have verified what the shim actually changes relative to upstream (version pin, patch, autoload shim, or replacement) and confirmed it's not carrying unexpected modifications.

Look elsewhere when:

• You're starting a greenfield project — use upstream phpmd/phpmd directly; the shim adds a dependency hop for no benefit unless you can name the constraint it unblocks.
• You need community support, documentation, or a security policy — 0 stars and 0 dependents means no ecosystem, no issue history, and no external eyes on the code.
• Your static-analysis requirements have outgrown PHPMD — PHPStan or Psalm offer stronger type-aware analysis and are actively maintained; a shim to PHPMD doesn't advance that goal.
• Compliance or supply-chain review applies — a self-hosted GitLab shim without public visibility, versioning guarantees, or a maintainer SLA is a poor fit for regulated or open-source-distributed products.
• You need cross-language or vendor-supported tooling — shims are inherently single-ecosystem and unsupported.

How to Pitch It (Stakeholders)

To executives: This is not a product feature — it's internal plumbing. It's a thin wrapper published by a research institute to make PHPMD, a PHP code-quality checker, install cleanly in a constrained Composer environment. It has effectively zero external adoption and no ecosystem behind it. The decision on the table is narrow: whether to inherit a small, unmaintained dependency in exchange for unblocking a static-analysis pipeline, and if so, for how long. Our recommendation is to treat it as a tactical, time-boxed bridge, not a strategic dependency, and to budget the cost of migrating to upstream PHPMD or to PHPStan.

To engineering: Use it only if you can articulate the exact Composer constraint conflict it resolves. Document that conflict in the repo, pin the version, and set a review date. Audit the diff against upstream before adopting — a shim should be boring and minimal. If it's more than a constraint patch, escalate. Do not introduce it into new services; use upstream or PHPStan. Add a dependabot-style check so we notice if it stops tracking upstream, and assign an owner so it doesn't silently rot.