[BUG] Parallelizing `npm version` in workspaces results in error

[jeffrson]

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

I run npm version via ultra-runner or xargs in parallel in >40 workspaces.

One or more calls fail because of "invalid" package.json - in one case (so far) package.json even had been cut to zero bytes.

AFAICT, executing npm version in a single workspace calls changeWorkspaces, which in turn reads every package.json inside the mono-repo via mapWorkspaces. Parallel npm version race, so later calls may find a package.json that has been started to convert (and may be temporarily empty).

Expected Behavior

npm version in a single workspace should not access other workspaces.

This is shown by --no-workspaces which works. But I always would need to remember to include it.

Maybe npm version should internally set --no-workspaces.

Steps To Reproduce

I have no explicit repro, but it's simple: have a workspace tree with ~40 or 50 workspaces.
Use ultra-runner or xargs to execute npm version patch --no-git-tag-version

Environment

• npm: 11.15 (starts with 8, afaict)
• Node.js: 22/24
• OS Name: Linux

[tangyuan0821]

I'll take this. Fix: default npm version to --no-workspaces internally. Assign me?

[alaminrifat]

Hi! Since no PR or activity has followed the earlier claim, I'd like to pick this up if it's still available.

My plan: set ignoreImplicitWorkspace = true on the version command, so npm version run from inside a workspace only touches that workspace's package.json — avoiding the setWorkspaces() traversal and root reify that race when invocations run in parallel (explicit --workspace / --workspaces behavior unchanged).

Could a maintainer confirm the direction and assign me? I'll follow up with a PR including tests.

[alaminrifat]

Opened #9730 with a fix.

One finding that changed the approach I originally proposed: the failure can happen before the version command even runs. When the cwd is inside a workspace, config load itself maps the whole monorepo (parsing every sibling package.json) to detect the workspace root — so a mid-write sibling kills any npm command at startup. It's deterministically reproducible by emptying one workspace's package.json and running any npm command from inside another workspace (--no-workspaces avoids it, matching what's described above).

The PR therefore fixes both layers: npm version no longer traverses the monorepo or reifies the root for an implicit single-workspace bump, and config load falls back to standalone (with a warning) instead of crashing when the workspace map is unreadable. With the fix, a 40-workspace fixture hammered with 12-way parallel npm version patch goes from intermittent EJSONPARSE failures to 0. Details and tests in the PR.

[MrTig-afk]

/assign