Ask anything to npm

npm is the package manager for Node.js. It was created in 2009 as an open source project to help JavaScript developers easily share packaged modules of code.

Ask npm about:

  • npm, Inc.
  • Node.js ecosystem
  • Getting started
  • npm Registry
  • OSS
  • Hiring

Hosted by:


Thank you all so much for the excellent questions!

Comments (46)

Add a comment
sy's photo

Is there any plan to provide a similar feature like yarn workspaces or improve npm link for better monorepo develop experience?

C J Silverio's photo

just some person on the Internet

The short answer here is yes. The longer answer is that we're still trying to figure out what to do, so I don't think we'll have anything to release soon. We're actively discussing what to do about workspaces inside monorepos. Some of us who work on very large OSS projects (like Ben Coe working on Istanbul) really like the lerna workflow for pulling together a lot of small modules.

You can expect improvements to npm link soon, however. I know that Rebecca Turner, our cli project lead, has had "make npm link work better" high on her to-do list for a couple of releases now, because npm 5 broke some common workflows there.

If you want to know the details what Rebecca is thinking, ping her on Twitter. Kat Marchán is also a good person to talk to about what you need from workspaces.

Sai Kishore Komanduri's photo

Greetings, CJ! Thanks for the AMA! :)

Whose idea was it to start the three-word thingies that randomly appear in the header of the npmjs.com website?

What has been your favourite npm-expansion so far? :)

Show all replies
Sai Kishore Komanduri's photo

Engineering an eGovernance Product | Hashnode Alumnus | I love pixel art

Haha, thanks for the best answer hands down! And yes, I did notice them 🎃.

Gordon Cooper's photo

How does npm decide which features to build next?

C J Silverio's photo

just some person on the Internet

Isaac, our CEO, is in charge of product design and direction at npm, so a lot of big projects start with him saying "this is what we need to build next!" It's then my job, as CTO, to figure out how to execute on that-- how to schedule it, how long it'll take (roughly), what the engineering dependencies are, who will need to work on it, and so on.

All of our scaling and maintenance projects come from me, because keeping the npm registry up & expanding under the load is a huge part of my job. I instigate a lot of forward-looking projects, aimed at handling next year's load, based on what I see happening with our current systems.

I also do a lot of listening to what my team tells me they think needs to be worked on next. This ranges from "hey our metrics workers are making too many connections and not scaling up as a result; we should fix it" to "this code base is really gnarly to work on and we know the problem space better now than we did two years ago; let's rewrite".

And still other projects happen because somebody says "darn it we should do this". Two-factor auth as a project happened because I did an implementation spike on my own, realized it was easy, and said it was time. We hid email addresses on our web site recently because somebody else said, hey! I know how we could do this without putting a huge burden on our support team, and we did it without a lot of planning or ceremony.

I do a lot of juggling of inputs like that to figure out what we can do with the humans we have, what needs to happen now, and what can wait. We are pretty flexible about what we do and we don't have a lot of rigid planning. I think we surf on the right side of flexible vs chaotic, anyway.

Deactivated User's photo

How do you approach planning new projects? In particular product work vs internal business requests. And the how do you sell these projects to your team?

C J Silverio's photo

just some person on the Internet

I wrote a bit about this in another answer, but really it's a mess and I am never sure if I'm doing it right. We can't do everything we want to do. I can list a dozen projects off the top of my head that I know we'll need to work on eventually that we can't imagine tackling today. The paradox of hiring is this is always true, no matter how many people you have on your team. The more you hire, the more your imagination expands. The scope of work you can conceive expands.

So it becomes a matter of balancing the urgent against the important.

I rarely try to sell projects. If you're doing the right project, and the information that led you to make that decision is shared, usually people can understand the decision.

When something's urgent, my team is usually the people who tell me about it, and I don't need to sell it to them. Or we've messed up by allowing a known tire fire to flare up into a user-visible problem. Sometimes I propose work and I get a huge wave of resistance-- this is a sign that I shouldn't even try to sell it because I'm just wrong. When the evidence is in favor of infrastructure work, the case is easy to make. (I'd bet that with infra work I'm more often telling my team to put it off than trying to sell them on doing it. Ugh, what a fate for a responsible engineer.)

Product work usually qualifies as "important" but rarely urgent. It has the trump card of coming from our CEO and of being the work that makes us money. We're all aware that to keep this sparking fountain of javascript sending OSS high into the night air, we need income. Bandwidth and servers are not cheap. So again, the team doesn't need to be sold on it. They need to understand it, absolutely, and to understand why we think it's the right thing to do as opposed to something else. But I think everybody at a small company deserves to have that kind of understanding. It's required if you want to enjoy all the advantages of having smart people build things for you. They'll make great decisions if they own it.

Deactivated User's photo

What are you favorite tech or non-tech practices on your team?

C J Silverio's photo

just some person on the Internet

We are a test-mad company and this is kinda great. Though I have seen the seamy underbelly of bad tests (tests that freeze your implementation not your interface make for far more work than they ever save). But wow, the testing culture here is strong and it makes for a lot of confident deploys.