The Slow Art of Patching: How NPM's Staged Releases Mirror the Patient Hobbyist

Why I'm Writing About NPM's Staged Releases on a Hobby Blog

You're probably here for knitting patterns or woodworking tips, not package managers. But stick with me. NPM just rolled out a feature that made me think of my grandfather's workshop—where every piece of wood was measured twice, cut once, and inspected before it ever became part of the furniture. That's the spirit of staged releases.

It's a deliberate act in a world that loves speed. And if there's one thing we hobbyists understand, it's the value of slowing down.

The New Staged Release Workflow: A Human Checkpoint

NPM's staged publishing adds an explicit approval step before a new package version goes live. Instead of publishing directly, the tarball goes to a staging queue visible on npmjs.com and in the CLI. A human maintainer then has to complete two-factor authentication to approve the release. No more instant gratification—just a pause.

That pause is the whole point. It's like letting a sourdough starter ferment overnight instead of rushing the loaf. The dough isn't ready until it's ready.

How the Commands Work: Step by Step

The workflow uses a set of subcommands that feel almost ritualistic:

• npm stage publish — submit the version to the stage queue
• npm stage list — see what's waiting for approval
• npm stage view <stage-id> — inspect the tarball
• npm stage approve <stage-id> — promote it, with 2FA prompt
• npm stage reject <stage-id> — discard it

Each step is a small, deliberate motion. It's not unlike the way I organize my fly-tying bench: every hook, feather, and thread has its place, and I check each one before the fly goes into the box.

The Technical Details: What You Need to Know

This isn't for everyone. You need npm CLI 11.15.0 or later, Node 22.14.0 or later, and the package must already exist in the registry. The staging phase doesn't require 2FA, so CI pipelines can still push non-interactively. The identity check happens at approval time.

GitHub recommends pairing this with OIDC-based trusted publishing. You can configure it to only allow staged publishes, rejecting direct npm publish. Teams already using bulk trusted publishing can reuse that config to migrate.

Why This Matters: The Security Wake-Up Call

This feature didn't appear in a vacuum. It follows a string of nasty supply-chain attacks, including the Shai-Hulud worm and the deprecation of traditional tokens. Security researcher Adnan Khan put it bluntly: every developer publishing to NPM should enable this now.

It's the same reason I started wearing safety glasses in the shop. One close call is enough to change your habits forever.

The Debate: Is Staged Publishing a Band-Aid?

Not everyone is thrilled. Hacker News user weinzierl called it a band-aid that might hurt long-term security efforts. But someone replied that for trusted publishing, it's a major improvement—it blocks a whole class of attacks aimed at hijacking CI environments.

Others question adoption. turkeyboi noted it only helps if maintainers actually use it. Klaster_1 asked whether it should be mandatory by default. On Reddit, a commenter argued it just slows down malicious package spread without fixing the root problem.

That sounds like every debate I've ever had about hand-planing versus power tools. Some people want the speed; others want the control.

Competitors Are Jumping In: The Arms Race of Patience

Other package managers are following suit quickly. pnpm 11.3 adds pnpm stage with the same subcommands. Yarn has its own version, and release-it supports a "stage": true option. pnpm also delays installing newly published versions by default—a defensive move.

It's like watching rival quilting guilds adopt the same slow-stitch technique. Everyone wants the bragging rights.

What's Next: The Future of Deliberate Publishing

GitHub has laid out a roadmap: fine-grained access tokens that can bypass 2FA will default to stage-only, and npm v12 will add an allowScripts field, with install scripts off by default. Plus new flags like --allow-file, --allow-remote, and --allow-directory—all configurable to all or none in .npmrc or package.json.

These changes are slow, measured, and deliberate. They remind me of the way I approach a new woodworking project: measure twice, cut once, and always leave time for a second look.

Lessons for the Hobbyist: Patience as a Feature

In a hobby like pottery, you can't rush the kiln. In NPM publishing, you can't rush the approval. The staged release is a reminder that sometimes the best thing you can do is wait.

So next time you're tempted to skip the sanding or publish without a second thought, remember the staged queue. It's not about being slow—it's about being sure.