The npm blog has been discontinued.
Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog.
npm registry is now fully HTTPS!
Effective yesterday morning, all requests to the npm registry are made via
- npm has accepted HTTPS or HTTP requests for some time. (In fact, only the initial hop from your client to Fastly, our CDN, would use HTTP.) We returned most data to you via HTTPS, but we would serve JSON containing package metadata over HTTP if you requested it via HTTP.
- Starting today, requests you make to the registry over HTTP still work, but we will return all data via HTTPS.
- In a few weeks, Fastly will redirect all HTTP requests to HTTPS. This won’t break your HTTP requests, but they’ll be a bit slower because of the redirect. You will be able to avoid that delay by using HTTPS in your first request.
Practically this means:
- If you request
http://registry.npmjs.org/pkgnameyou get a JSON response
- That JSON used to include
Now it’s https for the dist.tarball url,
- Soon, a request to
http://registry.npmjs.org/pkgnamewill 301 (redirect) over to
Does this mean that package data is/was insecure?
No! The CLI client checks a shashum to verify the package and that check always has been over HTTPS.
How it affects you
- It probably doesn’t. However, a small number of users currently replicate registry data using third-party tools such as Artifactory with configurations to only communicate insecurely.
- This is easily fixed by reconfiguring your tool, or by replicating the npm registry using another method.
How to weather these changes
We’ve developed an ecosystem of tools that you can use to replicate the registry in a way that is resilient to these changes:
For every change in a package in the registry, the whole package object (with changes) gets emitted as data on the
_changesfeed of CouchDB.
Users wishing to follow the changes feed can use our CouchDB follower wrapper, which will ensure you don’t miss any documents even if you process them asynchronously.
Finally, we also provide a normalizer, so that you can clean up the data you receive, and implement the changes from the changes feed.
We will never stop making replicating public packages utterly trivial. If anything, we’ll keep making it easier.
We believe these tools should minimize any disruption from our transition to HTTPS — but of course there are edge cases! If you experience difficulty, we want to hear about it and help you out. As always, don’t be shy to reach out: email@example.com.