pnpm / pnpm

Fast, disk space efficient package manager
https://pnpm.io
MIT License
29.37k stars 988 forks source link

ERR_PNPM_LINKED_PKG_DIR_NOT_FOUND in pnpm deploy #8159

Open zaverden opened 4 months ago

zaverden commented 4 months ago

Verify latest release

pnpm version

No response

Which area(s) of pnpm are affected? (leave empty if unsure)

Dependencies resolver, CLI

Link to the code that reproduces this issue or a replay of the bug

No response

Reproduction steps

This is a script to create a simple monorepo: ```bash mkdir -p \ libs/libs-b/b-1 \ libs/libs-b/b-2 \ apps/main # ======= b-1 ============== echo ' module.exports.b1 = () => "b1"; ' > libs/libs-b/b-1/index.js echo ' { "name": "@m/b-1", "main": "index.js" } ' > libs/libs-b/b-1/package.json # ======= b-2 ============== echo ' const { b1 } = require("@m/b-1"); module.exports.b2 = () => b1() + "b2"; ' > libs/libs-b/b-2/index.js echo ' { "name": "@m/b-2", "main": "index.js", "dependencies": { "@m/b-1": "workspace:../b-1" } } ' > libs/libs-b/b-2/package.json # ======= root ============== echo ' const { b1 } = require("@m/b-1"); const { b2 } = require("@m/b-2"); console.log(b1() + b2() + "apps-main"); ' > apps/main/index.js echo ' { "name": "@m/apps-main", "main": "index.js", "dependencies": { "@m/b-1": "workspace:../../libs/libs-b/b-1", "@m/b-2": "workspace:../../libs/libs-b/b-2" } } ' > apps/main/package.json echo ' packages: - . - ../libs/libs-b/b-1 - ../libs/libs-b/b-2 ' > apps/main/pnpm-workspace.yaml ```

After creating repo files, run

cd apps/main
pnpm install
node .
rm -rf ../../deploy && pnpm --filter {.} deploy --prod ../../deploy

Describe the Bug

By pnpm install && node . you can confirm that modules are installed and resolved correctly.

But running pnpm --filter {.} deploy --prod ../../deploy resolves to an error:

Packages are copied from the content-addressable store to the virtual store.
  Content-addressable store is at: ~/.local/share/pnpm/store/v3
  Virtual store is at:             ../../deploy/node_modules/.pnpm
 ERR_PNPM_LINKED_PKG_DIR_NOT_FOUND  Could not install from "~/pnpm-ws/apps/b-1" as it does not exist.

This error happened while installing the dependencies of @m/b-2@undefined
Progress: resolved 1, reused 0, downloaded 0, added 0

Deps graph is following

apps/main───►b-2
       │      │ 
       │      ▼ 
       └────►b-1

b-2 -> b-1 is linked as workspace:../b-1

For some reason, during deploy path ../b-1 is being resolved related to apps/main folder, but is was expected to be resolves from libs/libs-b/b-2 folder

Expected Behavior

deploy command completes without error and deploy folder contains ready-for-deploy code on apps/main

Which Node.js version are you using?

v20.8.0

Which operating systems have you used?

If your OS is a Linux based, which one it is? (Include the version if relevant)

Ubuntu 22.04.3 LTS

VladimirNT commented 4 months ago

After some debugging I found that the issue appears to be in resolveDependency function in pkg-manager/resolve-dependencies/src/resolveDependencies.ts

wantedDependency.pref contains relative path to the parent, including situations when parent is a peer, but ctx.storeController.requestPackage does not have any information about parent package treating everything as relative to root. For now I used the hack below (inserted before ctx.storeController.requestPackage call), but looks like working for deploy at least:

    if(wantedDependency.pref.startsWith('workspace:') && options.parentPkg.depPath.startsWith('file:')) {
      const parentRelRoot = options.parentPkg.depPath.split(":")[1];
      const depRelParent = wantedDependency.pref.split(":")[1];
      const depRelRoot = path.normalize(path.join(parentRelRoot, depRelParent));
      wantedDependency.pref = `workspace:${depRelRoot}`;
    }
zaverden commented 4 months ago

Unrelated to the issue, but I just noticed that packages are copied, not hard linked.

Packages are copied from the content-addressable store to the virtual store.

All folders are inside my homedir. Don't see a reason why there should me copy and not link. But I think it is a topic for another issue