JString Everything Node & Js Related
Uncategorized

Cover Your Apps While Still Using npm

Cover Your Apps While Still Using npm

Every once in a while, the JavaScript and Node.js ecosystem experiences something that is deeply disturbing to many developers: an outage of the npm registry.

Whenever this happens, we hear outcries that npm is the single point of failure for the entire ecosystem and that the entire ecosystem is doomed because of this.

In reality, the way that both the npm CLI and npm registry (and Yarn’s equivalents, for that matter) were built is extremely tolerant to enabling you to make reliable systems. The CLI is highly configurable and allows you to be registry agnostic–as long as the CLI gets the payload it expects from the registry it’s pointed at, it will install the module it’s instructed to install. Similarly, the npm registry is flexible and open–anyone can replicate the npm registry at any point, and there is a suite of options for registries across the globe.

We gravitate toward the default, though. It’s easy to get going with Node.js and npm and get lodash by just downloading Node.js and typing npm install lodash, so much so that we’re conditioned by the ecosystem to do this. There’s zero barrier to entry there, which is one of the most enabling parts of the ecosystem.

Cover Your Apps While Still Using npm

Default install instructions, provided by lodash: Just npm install it!

The default can be an issue, though, when you’re deploying JavaScript and Node.js applications that are critical–be it the platform that powers your business to the weekend project app that automates your home.

If you don’t take proper precautions to set up fail-safes for the modules and code that you rely on, you’re setting yourself up for a hard time when the next outage occurs. There are two relatively simple changes you can make–both reactively and proactively–that can ensure you don’t get caught without the code you depend on.

Independent Registries and Mirror Registries

Obviously, most people install from the default registry, registry.npmjs.com. This is only made clear by the sheer number of people expressing dismay whenever an outage occurs. Most people either don’t see a need (until they are impacted in dramatic fashion) or don’t know that you can change your default registry.

I’ve put together a list of registries that are currently up and running. I tested all of them, and was successfully able to install express@4.16.2 from each.

Cover Your Apps While Still Using npm

Setting my npm CLI’s registry to the Yarn registry and installing express@4.16.2.

There are a few severely outdated articles on the Internet outlining some of the public-facing mirrors of the npm registry, but most seem to have shut down since the articles were published.

Local Caching and Private Registries

In the event of a registry outage, the value of caching and private registries becomes evident. Until an outage, it’s a little bit less obvious, but if you need to be able to access your modules and dependencies reliably, going down the path of setting up local caching and/or a private registry is worthwhile and highly suggested.

Cover Your Apps While Still Using npm

The npm registry and all of it’s components are doing great _right now_. No need to worry. Really.

One interesting thing to note is that setting up tooling for local caching and private registries are usually entirely independent of your registry choice–so, choosing an alternative registry from the list above doesn’t impact your ability to begin using the features that local caching and private registries offer.

One last thing…

At NodeSource, addressing issues around Node.js, security, and stability of the platform is our number one goal. To explicitly help address the needs of businesses that are relying on Node.js and JavaScript, we’ve built both of our products–Certified Modules, an added layer of assurance around the module ecosystem and N|Solid, a drop-in replacement for the Node.js runtime–to help ensure you’ve got your apps covered no matter what.