fix(api): remove stale, divergent package-lock.json [BUG-104]

[Morenikeoa]

Problem

This project uses pnpm exclusively — .github/workflows/ci.yml and the Dockerfile both run pnpm install --frozen-lockfile and never reference package-lock.json anywhere. The file was nonetheless present in the repo and had drifted out of sync with pnpm-lock.yaml:

• It pinned a different @percolator/shared commit SHA than package.json/pnpm-lock.yaml.
• It resolved @percolatorct/sdk to the public npm registry (1.0.0-beta.33) instead of the file:../../percolator-sdk local monorepo path package.json actually declares.

Impact

Since nothing in this repo's real tooling uses package-lock.json, its only effect was risk: anyone — a new contributor unfamiliar with the pnpm requirement, or a future CI job misconfigured to use npm — running npm install instead of pnpm install would silently build and test against a stale, unrelated SDK version and a different shared-package commit, with no error raised.

Fix

Removed package-lock.json and added it to .gitignore so it can't be accidentally recommitted by running npm install locally.

Proof of Fix

Verified pnpm install --frozen-lockfile, the full test suite (294 baseline passing, same 1 pre-existing unrelated failure), and tsc --noEmit all still pass with the file gone — confirming nothing in this repo's actual tooling depended on it.

Related

Found during a broader API audit; distinct from open issue #198 (CI/Docker can't resolve the v17 SDK dependency at all — a hard failure case, not this silent-divergence case). No existing open issue/PR covers this.

[vercel]

@Princessdada is attempting to deploy a commit to the Khubair Nasir's projects Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

Warning

Review limit reached

@Morenikeoa, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 21 minutes and 48 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7bfb5697-9177-4827-832a-4f3890e10d32

📥 Commits

Reviewing files that changed from the base of the PR and between b2751f4 and d3e234a.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (1)

• .gitignore

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[dcccrypto]

Independent verification — not an approval (QA/Security own that). Verdict: safe, and the divergence is real and worse than "stale".

A deletion PR can't be mutation-tested, so I checked the two things that actually matter: does anything consume the file, and is the divergence claim true.

1. Nothing consumes it — deletion is safe

Every install path in the repo is pnpm:

Dockerfile:7                    RUN pnpm install --frozen-lockfile
.github/workflows/ci.yml:25     pnpm install --frozen-lockfile
.github/workflows/sdk-smoke.yml:77  pnpm install --frozen-lockfile

No npm ci, no npm install, no reference to package-lock.json anywhere in CI, the Dockerfile or package.json scripts. Removing it breaks no build path.

2. The divergence is concrete — it pins a different SDK version

Not hypothetical drift:

package-lock.json (main)  @percolatorct/sdk  1.0.0-beta.33
package.json  (truth)     @percolatorct/sdk  1.0.0-beta.34

So anyone who ran npm install in this repo would silently get an SDK version behind. Given how much of this codebase is mid-v17-convergence and how many bugs have turned out to be SDK-surface mismatches, an off-by-one SDK resolved from the wrong lockfile is a genuinely nasty way to lose an afternoon — the code would compile and the failure would surface as confusing runtime behaviour.

That upgrades this from housekeeping to a real footgun removal.

3. It prevents recurrence, which is the part I'd have asked for

The .gitignore entry means running npm install locally can't quietly re-commit the file, and the comment explains why rather than just muting it:

package-lock.json is npm's, not pnpm's — if it's present, npm install becomes possible and silently resolves dependencies differently than pnpm-lock.yaml does…

I've flagged several PRs recently for fixing a current state without preventing the next occurrence (#227's spec drift being the freshest). This one does both, and the reasoning is left in the file for whoever hits it next.

No changes requested from me.