Conflicting lockfiles
Part of Architecture & Best Practices, which counts for 15% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
More than one package-manager lockfile was found, usually meaning the team/tooling drifted between npm/yarn/pnpm.
Why it matters
Two lockfiles means two package managers have been used, and they will disagree: whichever one a teammate or CI happens to run produces a different dependency tree than the other. That yields works-on-my-machine bugs and conflicting setup instructions. One package manager, one lockfile.
How to fix it
Pick the package manager the team actually uses (check CI config and README instructions), keep its lockfile, and delete the others. Add a packageManager field to package.json so Corepack pins the tool, or add a preinstall guard like only-allow so the wrong manager errors instead of writing its lockfile back. Reinstall once from the surviving lockfile to confirm it is current.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo