[BUG] `npm version --save` drop workspace depending on alphabetical order

[louis-bompart]

Is there an existing issue for this?

• [X] I have searched the existing issues

This issue exists in the latest npm version

• [X] I am using the latest npm

Current Behavior

In one project, with 3 workspaces a, b, c (names matter) with:

• a depending on [b]
• c depending on [a and b]

Run: npm version -w=b --save patch

The package.json of c (the 'root') is not updated, and c now depends on the registry version of b instead of the workspace/local version.

Now, with these dependency conditions instead:

• a depending on [b and c]
• b depending on [c]

Run: npm version -w=c --save patch (to continue bumping the 'leaf' of the dependency tree)

The package.json of a (the root) is updated, and a still depends on the workspace/local version.

Expected Behavior

Regardless of the package names, when running npm version -w=somepackagename --save patch, I expect all the workspace of the project to be updated.

Steps To Reproduce

• Clone or reproduce: git clone https://github.com/louis-bompart/npm-version-ws-mrc.git
• Run npm version -w=d path --save --loglevel=silly
• Notice arborist only building the idealRoot of #root and a

npm timing arborist:ctor Completed in 0ms
npm timing arborist:ctor Completed in 0ms
npm timing idealTree:init Completed in 17ms
npm timing idealTree:userRequests Completed in 0ms
npm sill idealTree buildDeps
npm timing idealTree:#root Completed in 0ms
npm timing idealTree:a Completed in 0ms
npm http fetch GET 200 https://registry.npmjs.org/b 15ms (cache hit)
npm sill placeDep c [email protected] OK for: [email protected] want: 1.0.0
npm timing idealTree:c Completed in 21ms

Environment

• npm: v8.19.2
• Node.js: v16.16.0
• OS Name: W10
• npm config:

//localhost:4873/:_authToken = (protected)
//registry.npmjs.org/:_authToken = (protected)

; node bin location = C:\Program Files\nodejs\node.exe
; node version = v16.16.0
; npm local prefix = E:\Repos\npm-version-ws
; npm version = 8.19.2
; cwd = E:\Repos\npm-version-ws
; HOME = C:\Users\louis
; Run `npm config ls -l` to show all defaults.

[louis-bompart]

Some findings with the faulty (1st) scenario:

• During the loading of the tree, Edges from c to b are marked as INVALID
• During the loading of the tree, Edges from a to b are marked as OK
• During the building of the ideal tree, a->b is processed before c->b.
  • It adds b to the linkNodes Set

A solution then could be to modify the problemEdges by adding this condition early:

if (this[_linkNodes].has(edge.to)) {
 return false
}

However, I think the real oddity is that c->b is INVALID when a->b is OK and that's probably the real underlying issue.

[joeltg]

I finally found this bug after days of debugging my workspaces setup, and if I understand it right, this completely breaks the ability to use the NPM CLI to version and publish a monorepo of packages that depend on each other. Is anyone with more context and knowledge about NPM internals able to take a look at this?

[joeltg]

Anyone able to take a look at this? Seems to be a deep bug that requires a lot of context to unravel