Establishing Organizational npm Repository Over Nexus

Overview

The npm framework is a great engine for developing a variety of Node.js-based applications.

One of the greatest thing about npm, is the fact that it acts like an enormous registry, meaning: you can search for package , install the one you’d like, and publish your own packages out to the world.

This endless registry become more and more popular over the last years, and many organizations are using it as a important part of their code base.

However, been depended on an external registry can pose some major concerns when it comes to stability and code protection:

Build Stability

This is no secret that many of the available npm packages suffers from lake of stability and quality assurance.
This fact may be a minor issue for individuals or small organization, but for operating organizations this issue become a critical problem, due to their need to be able to keep their product versions/builds stable as it possible.

Moreover, event when an organization is able to produce a stable build - the consist publication stream to npm, raise a reasonable change for the next build to fail, regardless the actual change made on the core code base.

Code Protection

Another painful issue, is the ability to protect internal organizational IP (e.g. source code, data models, algorithms et cetera).
If we’ll choose to use the default public npm repository, all our published packages will be exposed to to the world. In case of front-end js/ts source code, the problem becomes even more urgent because the final artifacts are the actual source code or the transpiled code.

The Solution: Private npm Repository

In order to be able to preserve build stability, and protect important IP assets, but still enjoy all the benefits of npm global community, we should establish our own private organizational npm repository that will holds all out inner npm package.

Note: we use the private repository as internal npm registry, do not confuse it with source control management system! this repo will holds our published packages, not their source!

In this article, I’ll use Nexus 3 as the npm internal registry.
Note that there are other solutions based different artifact servers.

NPM Repository Setup

Log in to your Nexus server, and click on Create repository button:

Create new repository

Our solution configuration will be a combination of three Nexus repository types:

1. npm hosted- for internal npm packaged kept on our Nexus server.
2. npm proxy- proxy repository to to the global npm registry.
3. npm group- a group of the two first repos.

npm repository types

First, create a new npm proxy repository:

• Set the “Name” filed to be npm-proxy (or any other name you’d like).
• In the “Remote storage” set the url to: https://registry.npmjs.com.
• Leave all other properties with their default values.

npm-proxy repositort

Now, we’ll define the internal npm repository:

• Create new npm hosted repository.
• Set the “Name” filed to be npm-internal (or any other name you’d like).
• Leave all other properties with their default values.

npm hosted repository

The last repository is a group of the two repositories we’ve defined earlier:

• Create new npm group repository.
• Set the “Name” filed to be npm-all (or any other name you’d like).
• Add the two other npm repos as members.
• Leave all other properties with their default values.

npm group repository

NPM Configuration

Now, that we’ve established our own npm registry, all that left to do is to configure our local npm to work against this private registry.

• In your .npmrc file (should be located on your project root directory, if it’s not there- create in manually): add the following lines:

registry=http://<nexuse_server_address>/repository/npm-all/
_auth=<your_auth_token>

The auth token can be obtain by executing the following command:
echo -n ‘<nexus_user_name>:<nexus_user_password>’ | openssl base64

• In your packge.json add the following entry:
  …
  “publishConfig”: {
  “registry”: “http://<nexuse_server_address>/repository/npm-internal/"
  },
  …

Due to our new configuration each “npm install” command will first check if the requested package was already downloaded to Nexus server, if so it will fetch it immediately, otherwise- the new package will be downloaded from the external global npm registry (using our proxy repository), and then will be served to the client.

Every “npm publish” command will publish the package directly to the internal repository, so it will not be exposed to the external world.

Summary

In this article we’ve demonstrate how a private npm registry helps organizations to mange npm development but still keep their releases stabled and protect their code.