You can use a workaround. In the root package.json of your workspace, use pnpm.overrides. Let's say you want to link foo from a local directory, put this in the pnpm.overrides:

{
  "pnpm": {
    "overrides": {
      "foo": "<dir>"
    }
}

then just run pnpm install.

related: #3054

@zkochan This is not working as expected for me:

{
  "dependencies": {
     "foo": "0.0.1",
  },
  "pnpm": {
    "overrides": {
      "foo": "../foo"
    }
}

Still links to

foo -> .pnpm/foo@0.0.1/node_modules/foo

what about this:

{
  "dependencies": {
     "foo": "0.0.1",
  },
  "pnpm": {
    "overrides": {
      "foo": "link:../foo"
    }
}

@zkochan Nope, same result. Is pnpm.overrides only active inside workspaces?

Further background... I ran into this because my I found relative paths in my pnpm-lock.yaml which was making CI fail. So I started looking for a way to support local package links without affecting the lockfile and that led me here. But actually, it would be best to have maybe a .pnpm-local or some kind of file that didn't get committed so I could maintain local package links during development but update the lockfile after I had finalized changes to my forked deps under development concurrently. If you think that's a worthwhile discussion I'll make a new ticket for it :)

pnpm.overrides will result in relative paths in pnpm-lock.yaml as well. Why are modifications to pnpm-lock.yaml an issue? Because you accidentally committed them?

@zkochan Well that's a good point, packages intended to be used as a dependency generally shouldn't have a lockfile committed. But top level packages like a monorepo may have a lockfile so a dev team can all work against the same deps and have repeatable builds. In those cases, CI would fail if the lockfile contained paths only present in a local dev environment. I assume this is why npm link doesn't modify the lockfile.

I have a complex case where I'm trying to fork transient dependencies as well as direct dependencies. For example, my main monorepo depends upon a package I authored named georedis-promised. That package, in turn, depends upon a forked version of node-georedis. So my file structure looks like:

./monorepo
   {
      "dependencies": {
         "georedis-promised": "0.0.1", # link:../georedis-promised
      }
   }
./georedis-promised (benallfree/georedis-promised#master)
   {
      "dependencies": {
         "georedis": "0.0.1",  # link:../node-georedis
      }
   }
./node-georedis (from fork benallfree/node-georedis#typescript)

@zkochan Nope, same result. Is pnpm.overrides only active inside workspaces?

no, it works in non-workspaces as well. What pnpm version do you use? This feature was added in 5.10.1: https://pnpm.js.org/en/package_json#pnpmoverrides

@zkochan
Is there other way to do this?
I've started using turborepo with pnpm and the structure is like this

• apps
• packages (here i have subfolders like shared, and in shared i've installed shared deps, like rimraf)

Problem is, in apps I see the symlink from shared folder, but runninig inside apps/*, command like:
"dev": "rimraf node_modules" does not working, command is not found.
Is there a way with pnpm to know upstreams in monorepo about subfolders dependencies, like from packages/shared, or everything needs to be hoisted in the root folder?

@igortas this is not really related to this issue but if you need rimraf to be accessible in each package of the monorepo, then you need to install it as a dependencies in the root of the monorepo.

Like in case of the repository, these packages are available in all subpackages:

I'm also looking for this feature. In Yarn they call it --all (https://yarnpkg.com/cli/link#options-A%2C-all).