- How do I install and run systemsdk/phpcpd in a Laravel project?
- Install it as a dev-only dependency with composer require --dev systemsdk/phpcpd, then run vendor/bin/phpcpd app/ to scan your Laravel source. You get a usable duplication baseline in minutes, and you can wire it into Composer scripts, a Makefile target, or a CI job. No service provider or config publishing is required.
- Is systemsdk/phpcpd a drop-in replacement for sebastian/phpcpd?
- Yes. It is a maintained fork of the archived sebastian/phpcpd and keeps the same binary name, CLI flags, and PMD-CPD XML output. Migration is essentially a one-line composer.json change plus a lockfile update, and any downstream PMD consumer keeps working unchanged. The trade-off is that the fork inherits an older tokenizer, so verify behavior on modern syntax before relying on it.
- Does systemsdk/phpcpd need a Laravel service provider or affect production?
- No. It is a CLI-only developer tool installed as a require-dev dependency that exposes a single binary at vendor/bin/phpcpd. It never loads inside your Laravel application, so there is no service provider, facade, config file, or production surface area. Laravel version compatibility is effectively a non-issue; only the PHP runtime on dev machines and CI images matters.
- Which PHP versions does systemsdk/phpcpd support, and does it handle PHP 8.4 syntax?
- Check the package's composer.json PHP constraint and the maintainer's CI matrix, since those are the authoritative answer and should be verified rather than assumed for a fork. Newer syntax such as readonly classes, enums, property hooks, and asymmetric visibility can cause parse failures or silent mis-tokenization if the tokenizer has not been updated. Run it against a representative modern file and inspect the output before gating your pipeline on it.
- How do I make my CI pipeline fail when duplicate code is detected?
- phpcpd returns a non-zero exit code when duplicate blocks exceed your configured thresholds, so any CI system that respects exit codes will fail the build automatically. Tune sensitivity with --min-lines, --min-tokens, and --fuzzy so the gate is meaningful rather than noisy. Wire it into a Composer script, Makefile target, or dedicated pipeline step alongside your existing Pint and PHPStan jobs.
- Can I export phpcpd results to SonarQube, Jenkins, or GitLab?
- Yes. The --log-pmd flag writes PMD-CPD XML, a stable and widely consumed schema that SonarQube, Jenkins CPD plugins, and GitLab can ingest. You can combine it with normal console output in the same run, so developers still get readable results locally. Because the schema is unchanged from upstream, existing parsers and dashboards keep working after migrating.
- How do I exclude directories or files from phpcpd detection?
- The --exclude option takes a comma-separated list of paths, which is the usual way to skip migrations, generated code, vendor, or legacy directories. Confirm the exact flag set with vendor/bin/phpcpd --help on your installed version, since this fork may have diverged from upstream. Per-directory threshold overrides should be validated before you rely on them.
- Will systemsdk/phpcpd conflict with PHPUnit or other pinned dev dependencies?
- Possibly. The fork carries transitive sebastian/* dependencies that can collide with the versions PHPUnit or other dev tooling has pinned in your project. Run composer why-not systemsdk/phpcpd or a dry-run require to surface conflicts, and inspect the resolved lockfile before merging. If versions clash, isolate the tool in a separate Composer bin directory or a dedicated CI image.
- How does phpcpd fit alongside Laravel Pint, PHPStan, and PHPUnit?
- It is an orthogonal fourth quality dimension: Pint covers style, PHPStan and Larastan cover types, PHPUnit covers behavior, and phpcpd covers duplication. Because it only tokenizes files and never boots your application, it composes cleanly with those tools in the same pipeline. Keep it as a reporting or gated step rather than folding it into your unit test suite.
- Is systemsdk/phpcpd actively maintained and safe to adopt long term?
- Treat it with caution. Signals are weak: a low star count, a single-maintainer fork, an archived upstream project, and a repository field reported as unknown, which prevents provenance verification. A recent release date is reassuring but should be corroborated with real commit activity, a changelog, and a declared PHP version matrix. Architecturally it is low risk, so adopt it as a replaceable utility rather than a load-bearing quality gate.