deno manager binds nested package.json files to the root deno.lock, breaking lockFileMaintenance

[a-connoisseur]

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.29.5

Please tell us more about your question or problem

I have a repo where each subdirectory is its own standalone Deno project, each with its own deno.json, package.json and deno.lock. No npm or Deno workspaces anywhere.

The deno manager attaches all of the nested package.json files to the root deno.lock, on top of extracting them correctly against their own lock. So each one gets extracted twice. That's mostly harmless for normal updates, but lockFileMaintenance then deletes the root lock while running deno install inside a subdirectory, and the run ends with Artifact file update failure and only some of the lock files refreshed.

Smallest thing I could get it to happen with is two directories:

deno.json          {"nodeModulesDir":"manual"}
package.json       {"name":"root","private":true,"devDependencies":{"oxlint":"^1.65.0"}}
deno.lock          (deno install)
sub/deno.json      {"nodeModulesDir":"manual"}
sub/package.json   {"name":"sub","private":true,"dependencies":{"kysely":"^0.28.17"}}
sub/deno.lock      (cd sub && deno install)

Neither package.json has a workspaces field. Running LOG_LEVEL=debug RENOVATE_PLATFORM=local RENOVATE_DRY_RUN=extract renovate gives me this among the extracted package files:

{
  "deps": [
    {
      "depType": "dependencies",
      "depName": "kysely",
      "currentValue": "^0.28.17",
      "datasource": "npm",
      "prettyDepType": "dependency"
    }
  ],
  "managerData": {"packageName": "sub"},
  "packageFile": "sub/package.json",
  "lockFiles": ["deno.lock"]
}

kysely has no lockedVersion there because it isn't in the root lock. I'd expect sub/package.json to only ever be paired with sub/deno.lock.

From reading the source, collectPackageJson in lib/modules/manager/deno/compat.ts calls detectNodeCompatWorkspaces, which passes patterns: filters to find-packages. When the package.json has no workspaces field, filters is undefined, and find-packages falls back to its own default of ['.', '**'], so it globs every package.json in the tree and treats them all as members. normalizeWorkspace in post.ts doesn't undo it, since it only reassigns lockFiles for packages that match a declared workspace pattern and there aren't any.

The knock-on effect in updateArtifacts is that the (sub/package.json, lockFiles: ["deno.lock"]) entry deletes the root deno.lock, runs deno install --frozen=false with cwdFile under sub/ so only sub/deno.lock comes back, and then reads the root lock which is gone. The entry for the root package.json after it fails on readLocalFile with Failed to read "deno.lock", which is where the failed artifacts check comes from.

Versions: the failing PR was created by the hosted app on 44.29.5, and I reproduced the extraction locally on 44.31.0.

Logs (if relevant)

Logs

Hosted app job log for the renovate/lock-file-maintenance run, trimmed to the artifact stage. Repo name removed, tool-install noise dropped except the one exec that matters. Note the first e2e/package.json entry: it is working on the root deno.lock but the install runs in e2e/, so only e2e/deno.lock comes back and the root lock is gone from there on.

{"level": 30, "renovateVersion": "44.29.5", "msg": "Repository started"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(deno.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(e2e/package.json)"}
{"branch": "renovate/lock-file-maintenance", "command": "deno install --frozen=false", "msg": "Executing command"}
{"branch": "renovate/lock-file-maintenance", "stderr": "Dev dependencies:\n+ npm:@playwright/test 1.62.1\n+ npm:@types/node 25.9.5", "msg": "exec completed"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(e2e/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(e2e/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/backend/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/backend/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/backend/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/frontend/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/frontend/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/frontend/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/shared/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/shared/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "deno.updateArtifacts(packages/shared/package.json)"}
{"level": 20, "branch": "renovate/lock-file-maintenance", "msg": "Failed to read deno.lock. Skipping artifact update."}
{"level": 20, "branch": "renovate/lock-file-maintenance", "updatedArtifacts": ["packages/backend/deno.lock", "packages/frontend/deno.lock"], "msg": "Updated 2 lock files"}
{"level": 40, "branch": "renovate/lock-file-maintenance", "artifactErrors": [{"fileName": "deno.lock", "stderr": "Failed to read \"deno.lock\""}, {"fileName": "deno.lock", "stderr": "Failed to read \"deno.lock\""}, "... 9 more identical entries"], "msg": "artifactErrors"}

[MLuc24]

Your reading is right, and the cause is a missing guard rather than anything about your repo layout. It is collectPackageJson in lib/modules/manager/deno/compat.ts:

const lockFiles = [lockFile];
...
const rootPackageFile =
  await extractDenoCompatiblePackageJson(rootPackageJson);
if (rootPackageFile) {
  rootPackageFile.lockFiles = lockFiles;

  // detect node compat workspaces
  const result = await detectNodeCompatWorkspaces(rootPackageFile);
  const { workspaces, packagePaths } = result;
  ...
  for (const packagePath of packagePaths) {
    const packageFile = await extractDenoCompatiblePackageJson(packagePath);
    if (packageFile) {
      packageFile.lockFiles = lockFiles;
      packageFiles.push(packageFile);
    }
  }

lockFiles there is the root lock, and every package it finds gets assigned it. The question is why it finds yours at all when you have declared no workspaces, and that is in detectNodeCompatWorkspaces:

let filters: string[] | undefined;

// npm workspace
if (isNonEmptyArray(managerData?.workspaces)) {
  filters = managerData?.workspaces;
}

const packages = await findPackages(
  upath.dirname(ensureLocalPath(packageFile)),
  {
    patterns: filters,
    ignore: [...],
  },
);

With no workspaces declared, filters stays undefined, so findPackages gets patterns: undefined — instead of matching a workspace glob it walks the whole tree from the root and returns every package.json beneath it. Your standalone subprojects are not being misidentified as members; they are being swept up by a scan with no pattern to constrain it.

What makes this look like an oversight rather than a decision is that the other caller guards for exactly this case. In post.ts:

const workspaceRoots = packageFiles.filter(
  (pkg) =>
    isNonEmptyArray(pkg.managerData?.workspaces) &&
    upath.basename(pkg.packageFile).startsWith('deno.json'),
);

Same function called downstream, same lockFiles assignment from the root — but only when workspaces is actually non-empty. collectPackageJson calls it unconditionally, and that is the path you have landed on.

That also accounts for the double extraction you noticed. Your subprojects get picked up correctly against their own locks by the normal route, and then again here against the root's, which is harmless until lockFileMaintenance acts on the root lock while believing those packages belong to it.

Worth filing as an issue with that comparison in it. The fix is small — skip the loop when no workspaces are declared, mirroring the post.ts guard — and two call sites disagreeing about the same precondition is a strong argument that the current behaviour was never intended.

[RahulGautamSingh]

Issue Created: #45342

PR welcome!