Phpmd Shim Laravel Package

Technical Evaluation

Architecture fit. A "shim repository" for phpmd/phpmd is a metadata mirror: it republishes upstream PHPMD (the PHP Mess Detector CLI) under a host that Composer can reach, so a project can require it without hitting GitHub directly. It is a build-time artifact only — PHPMD is a static analysis tool, never a runtime dependency of a Laravel application. That constrains the fit: it belongs in the quality gate (CI, pre-commit), not in the deployable. Its architectural value is supply-chain control, not functionality.

Integration feasibility. Technically trivial. Consuming a shim means adding a repositories entry (type: vcs) and either requiring the shim package or relying on its replace of phpmd/phpmd, then regenerating the lockfile. The real feasibility question is access: the repo lives on gitlab.irstea.fr, an internal GitLab belonging to a French research institute (IRSTEA, merged into INRAE in 2020). Unless the project is public and unauthenticated, only that organization can consume it.

Technical risk. The risk profile is inverted — you are not adding a risky dependency, you are adding a middleman to a well-known one. Specific exposures: tag drift between shim and upstream (phantom versions, non-reproducible lockfiles), divergence in the shim's composer.json constraints versus upstream's (breaking transitive resolution of pdepend, Symfony components), and silent staleness when upstream ships a security fix. The zero stars / zero dependents signal means no community oversight, no Packagist security-advisory coverage, and no third-party validation of tag integrity.

Key questions.

• Does the shim mirror upstream tags 1:1, or use Composer's replace/provide to alias them? Is the alias pinned?
• Is there an automated job verifying tag parity and composer.json fidelity against phpmd/phpmd?
• What is the sync cadence — days, weeks, or has it been abandoned?
• Is the repository public, or auth-gated to INRAE?
• Is it registered on Packagist or consumable only via vcs repository entry?
• Who owns it internally, and what happens to it under INRAE's reorganization?

Integration Approach

Stack fit. Require in require-dev only, under PHP 8.x. PHPMD version 2.x is the current line; verify the shim advertises it. Laravel version is irrelevant to PHPMD itself — the only shared surface is PSR-4 autoload resolution, which a shim should not touch.

Migration path. If already using upstream phpmd/phpmd: add the repositories block, swap the requirement, regenerate composer.lock, and diff the resolved tree against the prior lockfile to confirm identical transitive versions. If not currently using PHPMD: first justify the tool at all — a Laravel codebase already running PHPStan, Pint, and PHPUnit may not gain enough from PHPMD to warrant an unsupported delivery path.

Compatibility. Confirm Composer 2.x handling, PHP constraint coverage, and whether the shim adds anything beyond metadata (it should not — any added autoload or scripts warrants scrutiny). Validate against your CI's Composer cache configuration, since VCS-type repositories bypass Packagist's CDN.

Sequencing.

1. Establish the motive: network isolation, version fork, or organizational policy. If none applies, skip the shim and depend on upstream directly through a Packagist mirror (Satis, Private Packagist, or a proxy).
2. Byte-compare the shim's composer.json and one known tag against upstream.
3. Add to require-dev on a branch; run the full suite plus composer validate --strict.
4. Wire PHPMD into CI non-blocking against a baseline ruleset.
5. Flip to blocking once the baseline is clean.
6. Add a scheduled drift check comparing shim tags to upstream tags.

Operational Impact

Maintenance. Registry score of 0 with no dependents effectively classifies this as unmaintained, and you will be the sole consumer. The sync obligation sits with the shim owner at INRAE or, failing that, with you if you vendor it. Given the institute's 2020 merger, repository continuity is a genuine concern, not a theoretical one.

Support. No community channel, no issue tracker with external users, no advisory feed. Escalation is a named individual or team inside a third-party research institute. That is an acceptable arrangement for a shared internal tool and an unacceptable one for anything on a production dependency path.

Scaling. PHPMD itself scales adequately — it is CLI-bound, memory-limited on very large codebases, and tunable via --minimumpriority and rule exclusion sets. The shim scales not at all; it is a static pointer, and its only failure characteristic is that it is a single point of failure in the install path. Mitigate by mirroring into infrastructure you control rather than depending on an external org's GitLab.

Failure modes.

• Shim goes stale and blocks a PHPMD or PDepend security update — highest severity, silent.
• Repository becomes private, renamed, or deleted — composer install fails outright for every engineer and every CI runner.
• Tag drift causes a version string to resolve to different content than upstream — non-reproducible builds, hard to bisect.
• Metadata divergence breaks transitive dependency resolution.
• No dependents means you are the first to encounter any change; no upstream canary population exists.

Ramp-up. Engineering ramp-up is near zero — PHPMD is a familiar CLI and configuration is a phpmd.xml file. The real cost is organizational: documenting why the shim exists, who owns it, how to audit a new tag, and the documented escape hatch to bypass it and pin upstream directly if it breaks. Budget roughly half a day for the initial fidelity audit and CI wiring, plus a recurring monthly check of tag parity.