There’s been a lot of activity on npm lately!
We’re sending 280 million tarballs to users each month.
To put that in perspective, when we started npm, Inc. a few months ago, that number was at 113 million. This time last year, it was 13 million.
Each download is a single
200 response code for a
.tgz file. Considering cache hits and JSON responses, this amounts to several billion requests each month.
At peak times, the registry is handling around 1500 requests per second. Thanks, Fastly!
April (and so far, May) was free of any measurable downtime for the public npm registry, and website stability has likewise increased in leaps and bounds.
There have been some isolated incidents that affected users in one geographic location or another, but we’ve been continually adding monitoring and alerts to detect problems well in advance of users being impacted.
The new status page now lists a few helpful checks, as well as checks for some of the underlying services we rely on. That also keeps status reports off of this blog, which is a plus :)
npm CLI Project Activity
Besides keeping the registry up, we also created this company to focus on development of the npm software. Some of these developments will presumably lead to paying customers.
In order to charge for private module hosting, we need a forward-compatible way to express that a package is owned by a specific entity that may involve access controls. However, the way we express that can’t stomp on any existing syntax, thus breaking backwards compatibility.
The discussion around namespaced packages exposed a handful of interesting issues that will inform the development of this feature. Watch this blog for more details soon.
As of the latest release, you can now specify config values on a per-project basis. This is especially helpful if you want a project to publish to and install from a specific private registry. Just put a
.npmrc file in the root of your project with the config values.
The handling of the
cache folder has been undergoing a significant refactoring. An entire tarball pack/unpack step was refactored out, making installs significantly faster. JSON data is now cached on a per-registry basis, eliminating a source of spurious ETag conflicts and bizarre search results.
The default log level has been reduced, so npm is a lot quieter. Rather than print out every HTTP request, npm now simply shows a spinner while it does stuff (so you know it hasn’t completely frozen). You can disable the spinner if you’d like with
--no-spin, or disable it permanently with
npm config set spin false. (It only shows the spinner if
stderr is a terminal.)
It’s truly amazing what a team of smart people can do, once they’re no longer putting out fires!
The npm website is a pretty ok proof of concept, but not what anyone would call “finished”. We’ve been going through the UX/Design exercises to figure out how to make it into something that’s much more useful and informative.
Progress on our private npm beta is moving very quickly. Once we can put the beta in the hands of our helpful early adopters, we’ll be focusing on the polish and “last mile” of this product, so that it’s easy for smaller shops to take advantage of it.
My hope is that, by the end of the year, we’ll be able to ship private modules in the public npm registry. We’re taking things slowly on that front, because we want to make sure that we can come up with a payment story that’s simple enough to understand easily, and doesn’t disrupt the existing incentives and community good will.
Speaking of community, npm will be sponsoring the coffee at JSConf US next week. The whole company is going to be there. Come and hit us up for stickers, and you can complain about your favorite npm bug :)
A month later, we’ll see you in the woods, at NodeConf.