Flagging Fresh Dependencies

Recently published versions are risky here for two reasons: supply-chain exposure, and the Azure Artifacts feed (.azure-pipelines/.npmrc) may not have synced them yet, so CI fails with npm error 404 ... Cannot find the file <pkg>-<ver>.tgz in package ... in feed 'vscode-documentdb'. Dependabot bumps land within hours of a release, so this happens regularly.

Step 1 — Scan (script)

node .github/skills/flagging-fresh-dependencies/scripts/find-fresh-dependencies.mjs

Scans package-lock.json and api/package-lock.json against the public npm registry (takes ~20 s for ~1,800 versions; publish time comes from the registry time map, which is authoritative). Prints each fresh name@version with age, UTC publish time, prod/dev scope, and the dependency chain to a declared dependency (via).

Zero results is a valid answer: say so, with the counts printed by the script. If exit code is 3, rerun before concluding anything.

To check what main would bring in, scan the lockfile from origin/main instead of the working tree.

Step 2 — Trace each fresh package (LLM, use gh/git)

For every hit, find who introduced that exact version. Do not use git blame on the current file only; search history for the resolved tarball:

# Commits that added/removed this exact version (oldest first). The first one is the bump.
git log --all --reverse --date=iso-strict --format='%H%x09%aI%x09%an%x09%s' \
  -S'<name>-<version>.tgz' -- package-lock.json

# PR(s) containing that commit
gh api repos/microsoft/vscode-documentdb/commits/<sha>/pulls \
  --jq '.[] | {number,title,merged_at,html_url}'

# Approvals and merge
gh pr view <n> --repo microsoft/vscode-documentdb \
  --json title,author,reviewDecision,reviews,mergedAt,mergedBy,mergeCommit

Gotchas:

• Dependabot PRs are merged as merge commits: the branch commit (-S hit) differs from the merge commit (mergeCommit). Both belong to the same PR; use the commit-to-PR API above.
• A -S hit can also be a later commit that re-touched the lockfile (e.g. a rebase or "baseline checkpoint"). The bump is the earliest commit in history that adds the version.
• Approver = a review with state: APPROVED (with commit.oid and submittedAt). COMMENTED reviews (including Copilot's "wasn't able to review any files") are not approvals. mergedBy may differ from the approver.
• A transitive dependency can also arrive via a PR that changed a different package (via shows the parent). Report the PR that actually changed the lockfile line, not the one for the parent name.
• Report times in UTC and the user's local time, and compute deltas (publish → lock commit → approval → merge) from the raw timestamps.

Step 3 — Report

One row per fresh package:

Then the notable timing (e.g. "bumped 3 h 44 min after publish; approved 10 s before merge") and, when relevant, the feed-404 implication. Do not modify anything unless asked.

If asked to revert

Use a branch (the user named dev/tnaum/dependency-update before) and revert the whole PR, since bumps pull in sibling packages (a browserslist bump also moves caniuse-lite, electron-to-chromium, node-releases, ...):

git revert -m 1 <merge-commit-sha>   # revert the merge commit of the Dependabot PR

Re-run the script afterwards to confirm the window is clean. Dependabot may re-propose the same bump; mention it.