Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

veripatch@0.2.0

Minor Changes

• 140144c Thanks @amarjaleelbanbhan! - New veripatch baseline list|add|remove|prune subcommands manage accepted debt one finding at
  a time: add records a reason and an optional expiry (--expires-days), after which the vuln
  counts as new again in scan --ci; prune drops entries whose vulns no longer appear in the
  last scan. baseline.json gains optional per-entry metadata, additively — existing files keep
  working unchanged.

• 281d079 Thanks @amarjaleelbanbhan! - npm workspaces are now scanned correctly from the monorepo root: workspace members'
  dependencies (including cross-workspace references through link entries) appear in the graph
  with provenance chains that name the owning workspace, e.g. root > @ws/lib > vulnerable-dep.
  Workspace members themselves are never reported as vulnerabilities — they are first-party code.

• 6f297e4 Thanks @amarjaleelbanbhan! - Transitive-dependency fixes are now applied the way a human would commit them: both the verify
  sandbox and veripatch update write an npm overrides entry and regenerate the lockfile,
  instead of running npm install pkg@to — which would have added the package as a new root
  dependency. Direct dependencies keep the plain versioned install.

• 10feb88 Thanks @amarjaleelbanbhan! - verify --all can run sandbox verifications in parallel: new verifyConcurrency config key
  (default 1, max 8) and --concurrency flag. Each verification keeps its own container,
  network, and staging copy; per-candidate output is buffered and printed in input order, so the
  transcript stays deterministic regardless of which sandbox finishes first.

• 6872cbf Thanks @amarjaleelbanbhan! - scan now supports pnpm projects: pnpm-lock.yaml v6 (pnpm 8) and v9 (pnpm 9+) are parsed
  into the same dependency graph as npm and yarn lockfiles, with peer-resolution suffixes merged
  into one node per package version. Lockfile auto-detection covers all three managers (npm →
  yarn → pnpm precedence, with a warning naming any ignored lockfile). verify and update
  refuse pnpm projects explicitly for now, matching the yarn behavior.

• c78b9cb Thanks @amarjaleelbanbhan! - scan now supports yarn projects: both classic (v1) and berry (v2+) yarn.lock files are
  parsed into the same dependency graph as npm lockfiles, with auto-detection when multiple
  lockfiles coexist (package-lock.json wins, with a warning). Reports gain a packageManager
  field. verify and update refuse yarn projects explicitly for now — they replay fixes with
  npm, and silently writing a package-lock.json into a yarn project would corrupt it.