Why the portal (yarn link) protocol cannot handle different versions of the same dependency?

[nickfla1-mxm]

Hello!

I'm starting this discussion because I cannot find an answer I can truly understand online, nor in the documentation.

When you use yarn link with a local package in a monorepo, if any of the packages using the linked dependency specify a dependency which does not have the same version specified in the linked package, it results in a failed linking step with error YN0071.

For instance:

• package foo specifies dependency baz at version 1.0.0.
• a monorepo uses yarn link to locally link foo
• package bar in the monorepo specifies foo and baz but at version 1.2.0

In this scenario yarn fails with the error:

Cannot link foo into bar dependency baz@1.0.0 conflicts with parent dependency@1.2.0

(example message)

My question is, why does the portal protocol need dependencies to be aligned, where if I install the package normally it is not a problem?

[clemyan]

During an install, Yarn itself will only write to locations "controlled" by it. This includes

• the project directory, including any node_modules directory under it
• the global folder
• etc.

(Of course, postinstall scripts can do whatever they want as always)

Notably, this means if you depend on a portal, Yarn can read from the target directory but will refuse to write to it. Otherwise it can lead to some dangerous situations:

• If the target is a project managed by npm or pnpm or even another version of Yarn, it may irrecoverably mangle it
• Yarn can be tricked into corrupting a system directory
• Yarn can be tricked into modifying the global npm's node_modules, including injecting malicious forks of certain dependencies

So if you use the nm linker, depend on a portal to /foo, and /foo depends on baz, but we can't write to /foo/node_modules, how can we install foo? Well if we run node with --preserve-symlinks, then foo can resolve dependencies from the projects own node_modules, which we can write to:

/project
  node_modules
    foo -> /foo
    baz

However, this means foo's dependencies must be installed to the top-level of the project's node_modules. As a consequence, foo requiring baz and the project requiring baz will always resolve to the same instance of baz. If the two needs incompatible versions of baz then this does not work.

if I install the package normally it is not a problem

If foo is a "regular" dependency, it will be installed under the project's node_modules. So unlike a portalled foo, Yarn controls foo's directory and can write to its node_modules

/project
  node_modules
    foo
      node_modules # <-- Yarn can write here
        baz@1.0.0
    baz@1.2.0

[nickfla1-mxm]

Thanks @clemyan, it makes total sense now 🙏