GeezerVison

Assisted-by: Claude Code:claude-opus-5-5

A hosted yarn classic pin written by v4 can install a patched package
whose package.json now asks for a newer dependency range (is-number
^7.0.0) while the lock still installs the old one (6.0.0). vex and
scan --vex only checked that node_modules/<dep> existed, so they
attested not_affected for a package that runs with the old dependency.

The installed check now finds the copy node actually loads (the
nearest node_modules/<dep>) and omits the patch with
dependency_not_installed when that copy's version is outside the
declared range. Ranges or versions the npm range reader can't decide,
and non-registry specs, are still never evidence.

The npm range reader moves from the yarn berry vendor backend to
utils::npm_range so both callers share it.

Refs #1538

Assisted-by: Claude Code:claude-opus-5-5

On a checkout with only package.json and yarn.lock, vex attested a
hosted yarn classic pin written by v4 even when the patched package
adds a dependency or bumps a range the lock never locked. Yarn 1
installs the dependencies the pinned block's sub-maps name, so such a
pin installs the patched package without what it now needs.

Discovery now keeps the pinned block of each hosted classic pin. When
a patch changes package.json and vex would attest it from the lock
alone, it reads the patched package.json (.socket/blobs, else the
patch API) and requires the block's dependency sub-maps to be exactly
the patched ones, each locked. Otherwise the patch is omitted with
dependency_not_installed, or dependency_manifest_unverifiable when the
patched package.json can't be read.

Fixes #1538

Assisted-by: Claude Code:claude-opus-5-5

- Skip the installed range check for a dependency the project forces
  with npm overrides, pnpm.overrides or yarn resolutions: its version
  is the user's choice, not a sign the patch is missing.
- Range-check installed optional dependencies too (absent ones are
  still fine), so installed and lock-only VEX agree.
- Compare a yarn classic block's sub-maps with the patched
  package.json by value, so `foo latest` (how yarn writes it) matches.
- Read the patched package.json blob from the manifest's .socket dir,
  accept only a 64-hex hash as its name, and check its size before
  reading it.
- Share the package.json record-key rule and compute the lock-only
  candidates once.

Refs #1538

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

The installed range check skipped any dependency an override key
merely mentioned: a nested npm override's parent (which only scopes
the overrides under it) counted as forced, and splitting keys on every
`/` made `@types/react` force `react`. Keys are now read with the yarn
selector parser (scope-aware), after pnpm's `>`, and a nested npm
override's parent counts only when its "." entry forces it.

Refs #1538

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

An npm override of "*" or "" (directly or as a nested override's "."
entry) keeps the declared range, so it doesn't force the dependency's
version and the installed copy is still range-checked. A "$name"
reference pins the root's own spec and still counts as forced.

Refs #1538

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

An override scoped under another package (yarn "mkdirp/minimist",
pnpm "mkdirp>minimist", npm {"mkdirp": {"minimist": ...}}) doesn't
touch the patched package's own copy of the dependency, so it no
longer skips the range check. Overrides are read as (parent, target)
pairs and count only when unscoped or scoped under the patched
package itself. A whitespace-padded "*" is a no-op like "*".

Refs #1538

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

A yarn resolution "mkdirp/**/minimist" only reaches minimist under
mkdirp, but the range check read the "**" as no parent and treated it
as forcing minimist everywhere. The parent is now the nearest segment
before the target that isn't "**"; only a leading "**/" applies
everywhere.

Refs #1538

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment