Finding two package managers is easy. Knowing whether they conflict is the hard part

Two lockfiles in one repository is not a defect. It is a question. Answering it is where almost all of the work is, and where a checker earns or loses your trust. Here are two contradictions we reported and what the maintainers actually did — and, because it matters more, the candidates we got wrong or deliberately walked away from.

Published and last checked 23 September 2026

1,394

active public JS/TS repositories screened

candidates deeply verified by hand

rejected — more than were published

The two that were real

OpsiMate/OpsiMate

A root package-lock.json deleted by the pnpm migration in d622a61 (22 August 2025) and re-landed two days later by #173. It sat stale ever since while dependabot kept maintaining pnpm-lock.yaml.

The maintainer independently verified the finding.
The maintainer asked for a pull request.
Separately, the maintainer found a second stray file we had missed: apps/client/bun.lockb.
Our PR #1020 removed the stale files and added ignore rules. It was merged.

What we got wrong. CrossCheck did not find apps/client/bun.lockb. The maintainer did. Our engine scopes contradictions within a package rather than reasoning from workspace authority, so a lockfile belonging to a workspace member was outside what it looked at. That gap is why the maintainer's review mattered.

Issue #1019 · Merged PR #1020

cortexkit/magic-context

A 123-byte pnpm-lock.yaml containing nothing but `importers: { .: {} }`, committed alongside bun.lock in 73f2969 — a dependabot sharp bump that also swept in two .build/ artifacts. packageManager declares bun@1.4.2 and roughly 25 CI steps run bun install.

The reported state was confirmed as accidental.
The repository corrected it on master in 3d049bf4.

What we got wrong. Communication on this one was bot-mediated. The corrective commit was human-authored, but we are not describing this as a human maintainer conversation, because it was not one.

Issue #499

The eight that were not

Every candidate gets read by a person before anything is filed. Most do not survive it. That rejection rate is the product, not a cost of it — an issue filed against a repository that was working as intended costs a maintainer time and costs us the only thing we have.

AIEraDev/Clypra

Everything the engine could see said npm: npm ci in all three workflows, npm install in README and CONTRIBUTING, no packageManager field. What it could not see was pnpm-workspace.yaml carrying pnpm's own allowBuilds and minimumReleaseAgeExclude settings, with three weeks of commit history behind them. pnpm was deliberate.

Outcome. The engine called this proven. It was wrong, and manual verification caught it before anything was posted. We then changed the engine: manager-specific configuration is now read as supporting evidence, and a finding like this leaves the proven tier and is reported as an ambiguity for review.

leeoniya/uPlot

package-lock.json and bun.lock are updated in the same commits — 6a34c82, 9e741bf, 22f3a0d — and bunfig.toml is present. That is deliberate dual maintenance, visible only in the commit history.

Outcome. The engine still calls this proven, because npm there has only a lockfile: no install steps, no configuration, so the new rule does not fire. We did not file anything. This is a known limitation we have not solved and are not pretending to have solved.

getnao/nao

AGENTS.md names bun as the backend runtime and both lockfiles are actively maintained.

Outcome. Deliberate. Nothing filed.

What this means if you run a repository

Static repository state cannot always establish intent. A repository that updates two lockfiles in the same commits, on purpose, looks identical at any single commit to one that abandoned a manager and left the lockfile behind. Telling them apart can require commit history. So a finding is a question worth asking, never a proven defect — and anything that tells you otherwise is guessing.

Check a public repository

The CrossCheck Quick Scan reads root package-manager signals in any public GitHub repository. No sign-in, no installation, no card. It tells you what it saw and says plainly when intent is unknown.

Paste a public repo into the free quick scan →

CrossCheck is MIT-licensed and runs in your own GitHub environment: github.com/zFinia/crosscheck.