Resolution failure is not actionable: error omits the failing package/specifier, debug output adds nothing, and a raw OS error leaks through (os error 123) #16590

Summary

When resolution fails because of a dependency specifier pnpm cannot handle, the error does not say which package, which version, or which specifier failed, and no reporter/log level adds that information. In addition, the underlying failure leaks out as a raw OS/filesystem error, which is misleading and not traceable back to any pnpm code path.

Error:   × installing dependencies
  ╰─▶ Failed to resolve dependency tree: Failed to resolve dependency: 檔案名稱、目錄名稱或磁碟區標籤語法錯誤。 (os error 123)

(檔案名稱、目錄名稱或磁碟區標籤語法錯誤。 is the localized Windows message for ERROR_INVALID_NAME, i.e. The filename, directory name, or volume label syntax is incorrect.)

This issue is not about whether pnpm should support that syntax — it is about the error reporting: the message is not actionable, the debugging output gives no extra detail, and there is no error code / traceable code path.

Reproduction

{
  "name": "probe",
  "version": "1.0.0",
  "dependencies": {
    "@yarnpkg/core": "4.9.2"
  }
}

pnpm install --lockfile-only

Result: the error above (os error 123 = ERROR_INVALID_NAME on Windows).

The previous version resolves fine, so nothing is wrong with the machine:

# with "@yarnpkg/core": "4.9.1" → resolves successfully
pnpm install --lockfile-only

Environment:

• pnpm: 12.9.1
• Node.js: v26.7.0
• OS: Windows (build 10.0.26300), x64

Root cause (found manually, by chance)

@yarnpkg/core@4.9.2 publishes a yarn-only specifier in its package.json:

"got": "patch:got@npm%3A11.8.2#~/.yarn/patches/got-npm-11.8.2-c1eb105458.patch"

while 4.9.1 had the plain range:

"got": "^11.7.0"

• npm: https://www.npmjs.com/package/@yarnpkg/core/v/4.9.2
• npm: https://www.npmjs.com/package/@yarnpkg/core/v/4.9.1
• Yarn issue: [Bug?]: installs fail on latest version due to relative path in got dependency yarnpkg/berry#7281
• Yarn fix PR (still open, 4.9.2 is still latest): fix(core): don't publish a project-relative got patch in @yarnpkg/core yarnpkg/berry#7282

pnpm cannot parse the specifier, and the failure ends up in the filesystem layer, so Windows reports os error 123.

Why this was so hard to debug

1. No package identity in the message — no name, no version, no raw specifier, so there is nothing to search for.
2. Debug/logging output adds nothing — --reporter ndjson, --loglevel debug, --ignore-scripts and --lockfile-only all produce the same two lines. The ndjson stream contains no event identifying the failing dependency.
3. Misleading error class — a dependency-spec problem is reported as a raw OS error ((os error 123)), which reads as disk/filesystem corruption. I restarted the machine several times suspecting a failing disk.
4. No traceable code path — no ERR_PNPM_* code, no pointer to the resolver stage that failed, so the message cannot be located in the pnpm source either.

Because of this, a lot of time went into wrong directions: deleting every node_modules and the global .pnpm-store, pnpm clean, pnpm store prune (machine-wide — every other project on the machine had to reinstall its dependencies), chasing unrelated deprecated warnings, allowedDeprecatedVersions, pnpm -r ls, copying single package.jsons into scratch folders, and several reboots suspecting hardware failure.

Suggested improvements

• Include name@version and the raw dependency specifier of the failing dependency in the error message.
• Emit a structured event with the same information for --reporter ndjson and --loglevel debug, so resolution failures can be traced without guessing.
• Wrap filesystem errors that occur during specifier resolution in an ERR_PNPM_* error with context, instead of leaking the raw OS error as the only explanation.
• Optionally provide a debug setting that logs each specifier as it is resolved, to locate the exact failing edge in the dependency graph.

Thanks for pnpm!