npm/cli

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

Open

#9,412 opened on May 27, 2026

View on GitHub
 (1 comment) (0 reactions) (0 assignees)JavaScript (3,025 forks)batch import
BugGood First IssueNeeds Triage

Repository metrics

Stars
 (7,529 stars)
PR merge metrics
 (Avg merge 3d 12h) (139 merged PRs in 30d)

Description

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

Contributor guide

Research direction
Investigate the race condition in npm version command when run in parallel across workspaces. Trace the code path from 'changeWorkspaces' to 'mapWorkspaces' and identify where workspace package.json files are read and written. Suggest implementing workspace level locking or using no workspaces automatically.
Tech stack
javascript
Domain
clitooling
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
None
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
60