Why
_read_lockfile only understands npm's package-lock.json (schema v1/v2/v3). Yarn and pnpm users silently fall back to the approximate range-strip path, so they get less precise version pinning than npm users.
What to do
- Extend the resolution in
parse_package_json (in sidecar/src/docchat_sidecar/lockfiles.py) so that when package-lock.json is absent it also checks for yarn.lock and pnpm-lock.yaml in the same dir and reads exact versions from them.
pnpm-lock.yaml is YAML (add a parser dep via uv add only if needed, or parse the small subset you need); yarn.lock is a custom format - a small line parser for the "name@range:" -> version "x.y.z" blocks is enough.- Set
Pin.source accordingly so the UI can still flag provenance.
Acceptance criteria
- Tests with fixture
yarn.lock and pnpm-lock.yaml snippets proving exact versions win over the manifest range.
- Full sidecar check pipeline green.
Pointers
_read_lockfile and parse_package_json in lockfiles.py.
Why
_read_lockfileonly understands npm'spackage-lock.json(schema v1/v2/v3). Yarn and pnpm users silently fall back to the approximate range-strip path, so they get less precise version pinning than npm users.What to do
parse_package_json(insidecar/src/docchat_sidecar/lockfiles.py) so that whenpackage-lock.jsonis absent it also checks foryarn.lockandpnpm-lock.yamlin the same dir and reads exact versions from them.pnpm-lock.yamlis YAML (add a parser dep viauv addonly if needed, or parse the small subset you need);yarn.lockis a custom format - a small line parser for the"name@range:"->version "x.y.z"blocks is enough.Pin.sourceaccordingly so the UI can still flag provenance.Acceptance criteria
yarn.lockandpnpm-lock.yamlsnippets proving exact versions win over the manifest range.Pointers
_read_lockfileandparse_package_jsoninlockfiles.py.