Phpcpd Laravel Package

Product Decisions This Supports

• Tech-debt prioritization and refactor budgeting. Duplication percentage becomes a measurable, trendable metric you can attach to a roadmap item ("reduce duplication in the Billing module from 18% → 8% this half") instead of an anecdotal complaint from engineers.
• Build vs. buy vs. skip for duplication analysis. This is a ~zero-cost, zero-integration OSS CLI. The real decision isn't "build vs. buy," it's "adopt a thin OSS detector vs. fold duplication into an existing platform (SonarQube, Qodana, CodeClimate) we already pay for." See the next section for the tiebreaker.
• CI quality-gate policy. Supports the decision of whether to enforce a duplication threshold on pull requests, and at what level (blocking gate vs. advisory warning vs. ratchet-only — fail if duplication increases relative to the base branch).
• Legacy/acquired-codebase assessment. Fast first-pass signal during due diligence or a platform migration: run it across a repo and get a duplication map in minutes, no licensing, no SaaS onboarding, no code leaving your network.
• Language/runtime upgrade planning. Because this is a maintained fork of the archived sebastian/phpcpd, it supports the decision to keep duplication coverage alive across PHP 8.x upgrades when the upstream tool stopped receiving releases.
• Team/ownership analysis. Cross-directory clone detection often reveals copy-paste across team boundaries — useful input for deciding where shared libraries or internal packages are worth funding.
• Use cases it directly enables: pre-refactor baselining, PR-level clone review, monorepo module health dashboards, "is this microservice actually a fork of that one?" investigations, and gating generated/vendored code out of duplication counts.

When to Consider This Package

Adopt when:

• Your stack is PHP-only and you want duplication detection with no SaaS dependency, no source-code egress, and no per-seat cost.
• You need something that runs in air-gapped or regulated CI (BSD-3-Clause, self-hosted, no telemetry).
• You want a cheap, reversible experiment — one Composer dev dependency plus a CI step; removing it costs nothing.
• You are already on the systemsdk tooling set or need a drop-in replacement for the archived sebastian/phpcpd with modern PHP support.
• You only need advisory, trend-level signal — you're not building a compliance gate on top of it.

Look elsewhere when:

• You already run SonarQube / SonarCloud / Qodana / CodeClimate / Codacy. They ship duplication detection with dashboards, history, and PR decoration. Adding a second, unintegrated detector creates a second source of truth nobody reconciles.
• You need multi-language coverage. Duplication in a PHP+JS+Go monorepo should not come from three separate tools; jscpd or a platform tool covers the polyglot case.
• You need a hard, auditable compliance gate. 15 stars and a single-maintainer lineage is thin assurance for something blocking releases — the bus factor and the abandonment history of the upstream project are both real.
• You need rich reporting. Expect CLI text output and exit codes; no HTML dashboard, no historical trend store, no PR annotations without glue code you write and own.
• Your organization requires vendor support, SLAs, or a security review with a named maintainer.

Adoption guardrails if you proceed: pin the exact version in composer.json, run it via a small in-repo wrapper script so the command surface is yours and not the package's, and define a written fallback (drop the step, or swap to the platform tool) so a stalled release doesn't block CI.

How to Pitch It (Stakeholders)

For executives (one paragraph): Duplicated code is a quiet tax — every copy is a place a bug must be fixed separately and a place a security patch can be missed. This is a small, free, open-source tool that scans our PHP codebase and reports where the same logic exists in multiple places, so we can put a number on that tax and track it down over time. It costs nothing to license, runs entirely inside our own infrastructure with no code leaving our environment, and takes roughly a day of engineering to wire into the build. The main caveat: it's a lightly-maintained community project, so we should treat it as a supporting signal rather than a compliance gate, and revisit it if we standardize on a paid code-quality platform. Recommended decision: approve a low-cost trial on one repository, measure what it finds, and decide in one quarter whether to keep it, drop it, or fold the capability into a platform we already pay for.

For engineering leads (the short version): It's a maintained fork of the abandoned sebastian/phpcpd — same token-based clone detection, now shipping on a modern release cadence. Install as a dev dependency, run in CI against changed paths, and start with an advisory threshold plus a ratchet (fail only if duplication increases). Do not make it a blocking gate on day one; do not let it scan vendor/ or generated code; and pin the version, because the maintainer base is small and this is the only fork keeping the tool alive. If we later buy a quality platform, retire it rather than run both.