npm is not the problem.
The release workflow is.

The gap

What npm doesn't do
for you.

Every time you release, you're manually handling things npm never promised to handle.

• Find every package in the correct order
• Understand local dependency relationships
• Install, build, and test in the right sequence
• Avoid publishing .env files and secrets
• Bump versions across packages without skipping one
• Push once after all publishes succeed
• Return clear exit codes for CI and agents
• Keep a record of what changed and what shipped

For code agents — 2.30.0

A stable contract for
agents and the developers overseeing them.

Code agents are good at commands, but bad at guessing release state. xnpm gives them a stable contract: discover the graph, resolve intent, return JSON plans, avoid hidden prompts, execute in dependency order, journal local changes, and report what happened.

• ✓
  Never hangNon-interactive runs exit with a useful code, not wait forever — see exit code 4 in Install → exit codes.
• ✓
  Plan before mutateInstall, publish, push, and dependency fixes are explainable before they run.
• ✓
  Machine-readable firstPlain-English ask is for humans; JSON plans and stable exit codes are for agents.
• ✓
  One graph, one release pathThe package graph and stack file become the release path, instead of one-off publish scripts.
• ✓
  Native tools, safer orchestrationUnder the hood it is still npm and git. xnpm adds graph discovery, safety checks, ordering, and recovery context.
• ✓
  Local dev stays localKeep local file: development links. xnpm can translate them for npm publish and restore them afterward.
• ✓
  Recovery is part of releaseLocal file changes are journaled, external effects are reported, and the developer overseeing the agent gets a handoff, not a chat log to decode.

Full contract — what an agent can run alone vs. what needs your --yes: Agents.

Before vs after

What a real multi-package
release looks like.

Next direction — not yet shipped

Real release work isn't
one command. It's a chain.

Releasing upstream usually means installing/updating downstream consumers, building and testing them, releasing downstream if needed, writing version-tagged feedback, and pushing the final repo state. xnpm should eventually understand that chain instead of only running the command in front of it — remembering the last release, knowing the previous release for each package, and recommending the next step. None of this is available today; it's the direction, not a feature list.