[BUG] Could not resolve dependency when using carrat ranges

[Nokel81]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

Given a monorepo with using npm workspaces and the following layout

application/
	- name: "my-application"
	- version: "1.4.5"
	- dependencies:
		- @foo/A: "^1.3.2"
		- @foo/B: "^6.10.2"
packages/
	a/
		- name: "@foo/A"
		- version: "1.3.2"
		 - peerDependencies:
			 - @foo/B: ^6.7.0
	b/
		- name: "@foo/B"
		- version: "6.10.2"

And if I run npm i due to needing to resolve conflicts in my package-lock.json or when I need to create my package-lock.json from scratch then I get the following error:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: @foo/A@1.3.2
npm ERR! Found: peer @foo/b@"^6.7.0" from @foo/A@1.3.2
npm ERR! packages/a
npm ERR!   @foo/A@1.3.2
npm ERR!   node_modules/@foo/A
npm ERR!     workspace packages/a from the root project
npm ERR!     1 more (lens-desktop)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @foo/b@"^6.7.0" from @foo/A@1.3.2
npm ERR! packages/a
npm ERR!   @foo/A@1.3.2
npm ERR!   node_modules/@foo/A
npm ERR!     workspace packages/a from the root project
npm ERR!     1 more (lens-desktop)
npm ERR!
npm ERR! Conflicting peer dependency: @foo/b@6.10.2
npm ERR! node_modules/@foo/b
npm ERR!   peer @foo/b@"^6.7.0" from @foo/A@1.3.2
npm ERR!   packages/a
npm ERR!     @foo/A@1.3.2
npm ERR!     node_modules/@foo/A
npm ERR!       workspace packages/a from the root project
npm ERR!       1 more (lens-desktop)
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

Expected Behavior

Given that 6.10.2 is compatible with ^6.7.0 this should install without any errors.

Environment

• npm: 9.8.0
• Node.js: v16.20.0

[Nokel81]

Upon further investigation, the problem seems to lie with

requested = npa.resolve(child.name, requested || '*', fromPath(requestor, requestor.edgesOut.get(child.name)))

on line 25 within @npmcli/arborist's dep-valid.js file, when the argument requested is a string (namely a file reference).

[Nokel81]

Which causes linkValid to return false.

[Nokel81]

Trying to fix this locally if I make the following diff

diff --git a/workspaces/arborist/lib/dep-valid.js b/workspaces/arborist/lib/dep-valid.js
index 4afb5e47c..a223fb1b8 100644
--- a/workspaces/arborist/lib/dep-valid.js
+++ b/workspaces/arborist/lib/dep-valid.js
@@ -120,8 +120,11 @@ const linkValid = (child, requested, requestor) => {
     return !isLink
   }
 
-  // directory must be a link to the specified folder
-  return isLink && relative(child.realpath, requested.fetchSpec) === ''
+  if (isLink) {
+    return relative(child.realpath, requested.fetchSpec) === '';
+  }
+
+  return path.isAbsolute(requested.fetchSpec);
 }
 
 const tarballValid = (child, requested, requestor) => {
diff --git a/workspaces/arborist/lib/node.js b/workspaces/arborist/lib/node.js
index bdc021b7c..eb653ea9e 100644
--- a/workspaces/arborist/lib/node.js
+++ b/workspaces/arborist/lib/node.js
@@ -1112,7 +1112,7 @@ class Node {
 
     // if they're links, they match if the targets match
     if (this.isLink) {
-      return node.isLink && this.target.matches(node.target)
+      return node.isLink && this.target?.matches(node.target)
     }
 
     // if they're two project root nodes, they're different if the paths differ

Then this error gets resolved and the packages end up in their expected places

[Nokel81]

Though this produces some oddities, so certainly not a complete solution.

• Local files are modified in the package.json to be link:false

[Nokel81]

Actually upon more investigation I think the issue is more to do with aborist's Node.isWorkspace getter. Namely, that a package defined within the workspace but listed as a peerDependency of another package within a different workspace (within the same monorepo) does not get flagged as a workspace dependency but instead as a peer dependency.

I noticed this because I looked at the formatting of the resolve error and it was bold instead of green

[Nokel81]

I think this has something to do with how the edge's get created, where the root entry in a monorepo (which does contain enough information to fix the isWorkspace bug meantioned before) is not actually passed down into the workspace packages themselves