A specifier that opens with a protocol no resolver supports, such as
Yarn's `patch:got@npm%3A11.8.2#~/.yarn/patches/...` published in
`@yarnpkg/core@4.9.2`, contains a `/`, so the local resolver claims it by
its path shape. Both stacks linked it to a directory that does not
exist. On Windows, pacquet instead failed with a bare `os error 123`:
Rust maps ERROR_INVALID_NAME to ErrorKind::InvalidFilename, so the
missing-directory fallback never ran.
When the local resolver finds that directory missing and the specifier
opens with a `<scheme>:` of two or more characters, both stacks now fail
with ERR_PNPM_UNSUPPORTED_PROTOCOL, naming the protocol and the
specifier, with a hint to replace it through `overrides`. The check runs
only on the missing-directory branch, so successful resolutions do no
extra work. In pacquet the error lives in resolver-base, and the tree
walker recovers it by downcast so the code survives the type-erased
resolver chain.
pnpm_fs::is_not_found treats Windows ERROR_INVALID_NAME as NotFound,
matching Node.js, and the manifest readers and the local resolver use
it. safe_read_package_json_from_dir reports other read failures with the
manifest path.
Closespnpm/pnpm#16590
Zoltan Kochan
1e5d031de9