npm workspaces: lockedVersion is null for hoisted deps, silently disabling OSV vulnerability detection

[sleukeleire]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

44.32.6

Please tell us more about your question or problem

npm workspaces: lockedVersion is null for hoisted deps, silently disabling OSV vulnerability detection

Describe the bug

In an npm workspaces monorepo with a single root package-lock.json (lockfileVersion 3), Renovate
resolves lockedVersion for a workspace package's dependency only if npm happened to nest that
dependency under <workspace>/node_modules/. For dependencies npm hoisted to the root
node_modules/, lockedVersion is null, even though the version is unambiguously present in the
lockfile.

On its own this is a minor annoyance. Combined with osvVulnerabilityAlerts, it silently disables
vulnerability detection for the large majority of dependencies, because
lib/workers/repository/process/vulnerabilities.ts requires a concrete version:

const depVersion = dep.lockedVersion ?? dep.currentVersion ?? dep.currentValue!;
if (!versioningApi.isVersion(depVersion)) {
  logger.debug(
    `Skipping vulnerability lookup for package ${packageName} due to unsupported version ${depVersion}`,
  );
  return null;
}

With lockedVersion === null the fallback is the range (^9.39.4), which is not a version, so the
package is skipped. The run reports success and creates no MRs.

Renovate version

44.32.6 (reproduced with renovate --platform=local)

Repository setup

• Platform: self-hosted GitLab (also reproduces with --platform=local)
• npm workspaces, workspaces: ["packages/*"], one root package-lock.json, lockfileVersion: 3
• 8 package files, 281 extracted deps

Root cause

lib/modules/manager/npm/extract/post/locked-versions.ts builds the lookup key from the package
file's directory relative to the lockfile, with no fallback:

const packageDir  = upath.dirname(packageFile.packageFile);   // packages/deployer
const npmRootDir  = upath.dirname(npmLock);                   // .
const relativeDir = upath.relative(npmRootDir, packageDir);   // packages/deployer

for (const dep of packageFile.deps) {
  if (dep.depType === 'engines' || dep.depType === 'packageManager' || dep.depType === 'volta') continue;
  let lockedDepName = dep.depName;
  if (relativeDir && relativeDir !== '.') {
    lockedDepName = `${relativeDir}/node_modules/${dep.depName}`;
  }
  dep.lockedVersion = semver.valid(lockFileCache[npmLock].lockedVersions?.[lockedDepName]);
}

And lib/modules/manager/npm/schema.ts normalises lockfile keys by stripping only a leading
node_modules/:

packages: LooseRecord(
  z.string()
    .transform((x) => x.replace(regEx(/^node_modules\//), ''))
    .refine((x) => x.trim() !== ''),
  z.object({ version: z.string() }),
)

So a hoisted entry node_modules/eslint becomes key eslint, while the lookup asks for
packages/deployer/node_modules/eslint. No match, no fallback, lockedVersion = null.

Reproduction / evidence

Lockfile contents (via python3, keys ending in the dep name):

lockfileVersion: 3
eslint    -> {'node_modules/eslint': '9.39.4'}
react     -> {'node_modules/react': '18.3.1'}
happy-dom -> {'node_modules/happy-dom': '20.10.2'}
moment    -> {'node_modules/moment': '2.30.1'}
chokidar  -> {'node_modules/chokidar': '2.1.8',
              'packages/deployer/node_modules/chokidar': '5.0.0',
              'node_modules/sass/node_modules/chokidar': '5.0.0', ...}
vite      -> {'node_modules/vite': '7.3.5',
              'packages/raf-rte-react/node_modules/vite': '6.4.3', ...}

What Renovate extracted:

Package file	dep	in lockfile as	lockedVersion
package.json (root)	esbuild	node_modules/esbuild	"0.28.1" ✅
packages/deployer/package.json	chokidar	packages/deployer/node_modules/chokidar	"5.0.0" ✅
packages/deployer/package.json	eslint	node_modules/eslint (hoisted)	null ❌
packages/react-component-library/package.json	react	node_modules/react (hoisted)	null ❌
packages/react-component-library/package.json	@types/node	packages/react-component-library/node_modules/@types/node	"20.19.43" ✅

The pattern is exactly "did npm nest it or hoist it", which should be irrelevant to determining the
installed version.

Impact with osvVulnerabilityAlerts: true

49 Skipping vulnerability lookup lines in a single run. The skipped set is not random — these are
all packages that have OSV advisories, i.e. Renovate looked them up in the DB and then could not
determine which version is installed:

eslint, react, react-dom, happy-dom, jsdom, moment, postcss, i18next, jszip,
lodash-es, validator, stylelint, react-router-dom, vitest, express, ...

The only package file where vulnerability detection works end-to-end is one that has its own
package-lock.json in the same directory (relativeDir === ''), where four advisories were
correctly found on body-parser and express.

Net effect: a repo configured for security-only updates receives alerts for a small minority of its
dependency tree, with no error, no warning, and no indication in the Dependency Dashboard.

Expected behaviour

For a workspace package file, if there is no nested <relativeDir>/node_modules/<dep> entry,
Renovate should fall back to the hoisted root entry — which is what npm's own resolution does.

Suggested fix

for (const dep of packageFile.deps) {
  if (dep.depType === 'engines' || dep.depType === 'packageManager' || dep.depType === 'volta') continue;
  const lockedVersions = lockFileCache[npmLock].lockedVersions;
  const nestedKey = relativeDir && relativeDir !== '.'
    ? `${relativeDir}/node_modules/${dep.depName}`
    : dep.depName;
  dep.lockedVersion =
    semver.valid(lockedVersions?.[nestedKey]) ??      // workspace-nested (existing behaviour)
    semver.valid(lockedVersions?.[dep.depName!]);     // hoisted fallback
}

Nested wins where present, so no existing behaviour changes; only the currently-null cases are
affected.

Workarounds attempted (both unsuccessful)

1. Refresh the lockfile — npm install --package-lock-only produced only cosmetic workspace
   version string changes. The entries were already correct; the lookup is the problem.
2. Let currentVersion fill the gap — removed the packageRules: [{matchPackageNames: ["*"], enabled: false}] rule so every dep would be looked up, hoping the second fetchVulnerabilities()
   pass would use dep.currentVersion. No change: still 49 skips and the same four advisories.
   currentVersion is not populated for range-only deps.

Anything else?

engines, packageManager and volta depTypes are explicitly skipped before locked-version
resolution, which is expected and unrelated — but it does mean engines.npm always appears in the
skip list, adding noise to the diagnosis.

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks