Skip to content

Add missing package-lock.json to code-reference-finder and research-sentry - #259

Open
Hotragn wants to merge 1 commit into
tinyfish-io:mainfrom
Hotragn:hotragn/add-missing-lockfiles
Open

Add missing package-lock.json to code-reference-finder and research-sentry#259
Hotragn wants to merge 1 commit into
tinyfish-io:mainfrom
Hotragn:hotragn/add-missing-lockfiles

Conversation

@Hotragn

@Hotragn Hotragn commented Aug 18, 2026

Copy link
Copy Markdown

code-reference-finder and research-sentry were the only two recipes with a package.json and no lockfile. Completes the dependency-hygiene thread from #251 / #253.

Why it matters

  • npm ci cannot run in either. No lock, no reproducible install.
  • Nothing is pinned. Every install re-resolves every caret range, so two people cloning a week apart can get different trees from identical source.
  • OSV-Scanner reads the lockfile. With none present, neither recipe's dependency tree is covered by the repo's own vulnerability scanning — same blind-spot argument as Regenerate tutor-finder package-lock.json so npm ci works #253, but total rather than partial.

I checked it wasn't deliberate first

A missing lockfile can be a choice, so before generating anything:

Signal code-reference-finder research-sentry
packageManager field absent absent
yarn.lock / pnpm-lock.yaml / bun.lockb none none
lockfile in .gitignore no — only node_modules/ no — only node_modules

No alternative package manager, nothing ignoring locks, and the other 30 recipes all commit one. It reads as an oversight.

The change

npm install --package-lock-only in each. No source changes, no package.json changes — the diff is two new files. lockfileVersion: 3 in both, matching all 32 existing lockfiles.

On pinning "@tiny-fish/sdk": "latest"

Both recipes declare the SDK as latest, and a lockfile freezes it — here to 0.4.1. Worth flagging explicitly, but it isn't a behaviour change: with no lockfile they were already installing whatever latest resolved to, which is 0.4.1 today. And it matches existing practice — 17 recipes already declare latest while committing a lock that pins it:

bestbet                    -> 0.0.7
stay-scout-hub             -> 0.0.9
wing-command               -> 0.0.11
... 14 more

Renovate is already configured here, so bumps stay managed the same way they are for every other recipe.

Verification

for r in code-reference-finder research-sentry; do
  (cd $r && rm -rf node_modules && npm ci && npx tsc --noEmit)
done

npm ci exits 0 and tsc --noEmit exits 0 in both, from a clean tree.

Two things I noticed while in here

1. code-reference-finder has broken lint — an 8th case for #248. Next 16.1.6 with "lint": "next lint", and no eslint.config.*, no eslint and no eslint-config-next:

$ npm run lint
> next lint
Invalid project directory provided, no such directory: .../code-reference-finder/lint
exit 1

Same shape as fast-qa in #258. I've left it out of this PR — adding ESLint means ~370 more lock entries, which would swamp a two-file change. Reported on #248.

research-sentry has no lint script at all, so there's nothing to break there.

2. Unrelated but reassuring for #244. These two now pin SDK 0.4.1, while the recipes with older locks sit on 0.0.7–0.0.11. I diffed the event contract across that range and it's unchanged — EventType is still STARTED | STREAMING_URL | PROGRESS | HEARTBEAT | COMPLETE, RunStatus still PENDING | RUNNING | COMPLETED | FAILED | CANCELLED, and the field names are still streaming_url, purpose, run_id, result, error. So the whitelist in #244's checker holds across every SDK version currently in the repo, not just the one I originally read it from.

Independent of every other open PR; touches only these two new files.

…entry

These were the only two recipes with a package.json and no lockfile, so
npm ci cannot run in either and there is nothing pinned: every install
re-resolves every caret range, and OSV-Scanner has no lock to read, which
means neither recipe's dependency tree is covered by the repo's own
vulnerability scanning.

Checked first that the absence looks accidental rather than deliberate.
Neither declares a packageManager, neither has a yarn/pnpm/bun lockfile,
and neither .gitignore mentions lockfiles -- both ignore only
node_modules. The other 30 recipes all commit one.

Generated with npm install --package-lock-only, so no source and no
package.json changes. lockfileVersion 3 in both, matching all 32 existing
lockfiles.

Both recipes declare "@tiny-fish/sdk": "latest", which the lock now pins
to 0.4.1. That is what an install already produced, so it is not a
behaviour change, and it matches how the repo already works: 17 recipes
declare latest and commit a lockfile pinning it.

Verified from scratch in both: rm -rf node_modules && npm ci exits 0, and
tsc --noEmit exits 0.
@coderabbitai

coderabbitai Bot commented Aug 18, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 24d4a7e4-c437-4b48-8820-c8759ee63b4a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant