Phpmd Config Laravel Package

Product Decisions This Supports

It informs quality-gate policy, not product features. irstea/phpmd-config is a curated PHP Mess Detector (PHPMD) ruleset — an XML configuration artifact. It will never appear in your product's runtime, your customer experience, or your Laravel dependency graph. The decisions it genuinely touches are engineering-process decisions a PM should own at the policy level:

• Definition of Done / merge-gate policy. Whether static analysis blocks merges, and at what thresholds (cyclomatic complexity, coupling, NPath, unused code, naming). A ruleset is the concrete artifact behind "we enforce complexity limits." PM owns whether and how strict; engineering owns the rule contents.
• Technical-debt roadmap sizing. PHPMD findings are a usable proxy metric for maintainability debt. Running any reasonable ruleset produces a baseline number ("412 complexity violations in the checkout module") you can trend, put in front of stakeholders, and roadmap against. That is a roadmap input this package can seed cheaply.
• Adopt vs. author (the real build-vs-buy). The comparison is not "buy a tool" — it's "reuse someone's phpmd.xml versus spend two hours writing our own." Near-zero cost either way, and not worth roadmap time. Treat the package as prior art that saves a drafting session.
• Review throughput and onboarding. A shared, non-negotiable ruleset removes subjective code-review debate and shortens time-to-first-PR for new engineers — a measurable enablement outcome you can cite when justifying the gate.
• Toolchain consolidation. If the team already runs Larastan/PHPStan and Pint, adding PHPMD is a marginal decision: more CI minutes and more red builds to triage. The PM question is "how many gates do we actually want, and which concern owns which gate" — not what's inside the XML.

What it does not justify: a product dependency, a migration project, or a security-review budget line. There is no PHP class, no service provider, no Laravel integration — it is configuration.

When to Consider This Package

Look at it only under narrow conditions:

• Your organisation is IRSTEA/INRAE-adjacent, or you're contracting into a French public-research codebase where this ruleset is already the house convention and consistency outweighs everything else.
• You want a ready-made, opinionated PHPMD threshold set as a starting draft and would rather edit an existing phpmd.xml than author one from scratch.
• You're standardising static analysis across several legacy PHP repos and need something to point at on day one — accepting you'll fork it within a sprint.
• You're introducing PHPMD specifically for complexity and design smells, the niche PHPStan covers poorly. It complements, never replaces, PHPStan/Larastan.

Look elsewhere — decisively — when:

• Maintenance and supply-chain risk matter (they do, for anything in your pipeline). Zero stars, zero dependents, single-organisation ownership, not on Packagist, and hosted on an external GitLab mean no bus factor, no release cadence, no tags. Pulling it at build time makes an unversioned external input a dependency of every CI run — a silently broken quality gate or a permanent red-build generator. Mirror the XML into your own repo and credit the source.
• You're on Laravel specifically. PHPMD is framework-agnostic and knows nothing about Eloquent, facades, or container bindings — it will flag idiomatic Laravel as "excessive coupling." Use Larastan/PHPStan for type correctness, Pint for formatting, and Enlightn for framework anti-patterns (N+1s, missing indexes, unsafe config).
• You need enforceable style rules. That's PHP_CodeSniffer with PSR-12/Slevomat, not PHPMD. Naming rules are the most common source of noisy overlap between the two.
• You need a defensible license. No license is declared in the metadata provided; treat that as "all rights reserved" until verified. Forking without a clear license is a genuine compliance question, not a hypothetical — resolve it before vendoring.
• You need supply-chain guarantees. A ruleset pulled from an unaffiliated GitLab at build time is an external input with no SLA.

Recommended default: vendor the XML into your repo, credit upstream, pin the source commit, and stop depending on the remote.

How to Pitch It (Stakeholders)

To executives (30 seconds): "This is not a product component — it's a linting configuration file from a French research institute. It has no users, no releases, and no license we can rely on. It cannot improve the product directly. It's useful only as a reference for how strict our automated code checks should be. My recommendation: do not take a dependency on it. Have an engineer spend half a day adapting its thresholds into a file we own, or lean on the Laravel-standard tools we already run. Cost of the internal route: near zero. Risk of the dependency route: a quality gate that breaks or goes silent and we don't notice for months."

To engineering: "This gives us a head start on PHPMD thresholds, but it's a single XML file with no maintenance and no license. Don't composer require it. Read it, merge the parts that match our stack into an in-repo .phpmd.xml, and pair it with Larastan (correctness) and Pint (style). One gate per concern — we're not stacking four overlapping analyzers on the same PR. Start non-blocking, run it a few weeks, baseline legacy paths, then flip to blocking for changed files only. Assign a named owner for the ruleset in CODEOWNERS."

The one-line product judgement: Treat irstea/phpmd-config as prior art, not a dependency. The decision it enables — "do we gate merges on complexity metrics, and at what threshold" — should be made and owned internally, independent of whether this package exists.