It's time to ditch Medium for good! 🌈⚡️

Introducing Devblog by Hashnode. Blog on your domain for FREE. Highly customizable and optimized for developers.

Learn more

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!

Ask a Question

46 discussions

First off thx! HUGE fan of the work produced by the humans of npm Inc. I use your product(s) every day and couldn't operate our business without npm and private modules. I was super lucky to get some time with Kat and they shared a bit about cipm with me. (It's awesome.) So I have two questions!

0.) Where does cipm fit in the npm story in teh coming year? 1.) What is being planned for the esmodules …situation… that tc39 opted our ecosystem into?

Thx again! 🙏💖

0) aaaaah I want to ship cipm so badly! This scratches an itch we have internally that is so very itchy.

A brief explainer: cipm or npm ci is an installation tool design for CI and deployment environments. If you have a package-lock.json file in your project, cipm will install what is described in that file. It will ignore what's in package.json and make no attempt to respect what's in node_modules. It merely blasts the desired installation tree to disk as fast as it can. With a warm cache, this results in installation times on the order of milliseconds per package. (The only speed improvements we are aware of on this, right now, come from un-gzipping in advance. Or writing it in C or something to memory-map the file. The next wave of perf improvements will come in major algorithmic changes in the API that get the cache hot in the first place, I think.)

Kat is working right now on integrating cipm inside of the main npm tool. I think we also need to get auth working for it, so there's some work yet before we get it out. But I'm hoping to ship it this year. This is sort of the culmination of plan that team has had for a while now of upending the model of how the npm cli does its work-- calculate a tree, record the calculation, trust the calculation, sync.

After we ship that, we have The Problem of ES Modules. We already have some internal experimentation on what the hell to do about this mess. I have John-David Dalton's esm on my exploration list. I think it might be a bridge forward.

Some handwavey statements: The server side of JS is largely irrelevant; the browser community is much larger & more actively creative. (Note that I say this even though I personally am a server-side js user, not a browser developer.) In 2 years, the majority of npm's registry will be ES6 modules. Nobody will remember this transitional pain.

Reply to this…

Share your programming knowledge and learn from the best developers on Hashnode

Get started

Hi Silverio, Thanks for hosting this AMA. :)

What's your opinion on Yarn and do you think npm 5 is better than it?

Better for what? What problem are you solving?

npm5 is a better general installation tool for most node users! yarn is a better installation tool for people who want a Bundler-style workflow!

Both of these answers are correct! Use the tool that fits your problem!

Reply to this…

What's the best part about working at npm? What do you look for before hiring an engineer?

Show all replies

What do I look for when hiring an engineer? Oh, wow, that's a deep question.

The ability to work with other human beings is #1. Are they empathetic to their users and to the people around them? Do they enjoy learning? How are they at communicating with their teammates? How do they handle disagreeing with somebody?

Can they work on a team? would be the summary question, I think. This is what distinguishes good programmers from great ones.

I take it as given that engineers I'm interviewing are smart people and can write software. This is the advantage of hiring at npm: I can safely assume that! This is such a surprising and wonderful experience that I've never had before at a company. (Downside: every time we hire I have to turn down amazing candidates who absolutely could be wonderful with us, but I can only pick one. This is painful.)

Reply to this…

Cheese on top of meat vs below the meat!

What do you and npm support? 🤨

I put this one to a vote inside npm: 100% of npm prefers Apple's burger to Google's. HOWEVER this does not end the controversy. Nobody was entirely happy with Apple's burger and the entire company then spent the next half hour arguing about how to fix Apple's burger. Everybody felt the lettuce belonged on top, guarding the bread from the tomato. The question was then where the tomato goes. Does it go right next to the meat? That's the best way to season the meat with tomato-ness. But the cheese needs to be on the meat to melt properly, so OMG the argument continued.

I personally resolve this by skipping tomato and just going for bun-meat-cheese-bacon-bun order.. This is the BMCBB stack. I recommend it to all javascript burger developers as a solid, time-proven tech stack to build any application on.

Also I will note that this one question brought everything inside the company to a halt. This is not the first time we've had a food-related internal schism, however. Don't ask any of us what you call the pastry that made with flaky croissant dough and chocolate.

Reply to this…

How does npm make the build vs buy (or use existing oss tech) decision?

Oh hey this is a fun question that I am never sure we have the right answer to.

The first thing to observe is that npm is absolutely stuffed to the gills with people who, over and over, decided they wanted to write their own whatever instead of going with the one that existed before. We were founded by somebody who led the node project during its early, obscure hipster days, who decided that the world needed another package manager. Early on we hired people who had experience with node when it was still edgy and unknown, so we have a lot of early-adopter questing minds among us. Then there's Ben Coe, who adopts projects like yargs and istanbul because they were mournful puppies who needed an owner.

So we're biased toward invention.

I like inventing things too. But because my team would invent all day every day, I have to put on the "let's use something not invented here" hat more often than I personally want to wear it.

No inventing our own databases! (Okay, that one's easy because we do not have the team to do that.)
No inventing our own testing framework! Well, um, we have node tap's inventor. And nyc's inventor. And istanbul's maintainer. Um.
No inventing our own http framework! We're using restify! Well, um, we invented one we'll be open-sourcing soon.
No inventing our own sql library! We're using knex! Well, um, we invented one we've already open-sourced.

We haven't written a promises library! We just use bluebird like everybody else.

So, um, the truthful answer is that if it's written in javascript, we might invent it ourselves just because this is our jouissance. If it's not written in javascript, we're more likely to restrain ourselves.

Reply to this…

Load more responses