Recently, I was working on a web application built on the MERN stack. Fortunately, it was developed using a modular approach. We built this with different modules for both React and Express applications.

Breaking things into smaller pieces of functionality gives us the power to reuse the code as well as  the following benefits:

  1. It increases the page load speed by on-demand script loading.
  2. It makes developers add features to a particular module without fuss.
  3. It adopts the current specifications of ES6 and makes JavaScript project viable in the future.

Using a modular approach is always preferable, but getting an entire project to build is a hassle as it takes too long for it to compile and build. If any developer makes changes to any of the modules, another developer has to pull and build the code first to get the changes reflected. In our case, the approximate time to build an entire project was around 30 mins. Honestly, if you ask me, that's too much!

We’ve all worked on projects which give us an opportunity to build reusable components. Most of the times these components end up in the shared folder of the project. This folder then gets copy-pasted into several projects which, over time, become a nightmare to update as it’s not easy to have multiple versions of a component and maintain the same code based on multiple branches, as versions are kind of a hacky solution to thIn order to be able to preserve build stability and reduce build time, but still, enjoy the benefits of the NPM global community, we started using Nexus Repository Manager, which is an open source repository manager provided by Sonatype.
It helped us to establish our own private organizational NPM repository that holds our internal NPM packages and also reduces build time to 5 mins.
is problem.

The Solution: Nexus Repository Manager

In order to be able to preserve build stability and reduce build time, but still, enjoy the benefits of the NPM global community, we started using Nexus Repository Manager, which is an open source repository manager provided by Sonatype.


It helped us to establish our own private organizational NPM repository that holds our internal NPM packages and also reduces build time to 5 mins.

How Does the Repository Manager work?

You can think of a repository like a library. It is a server that stores and retrieves files that we refer to as artifacts/packages. When you write a piece of software, you often depend on external libraries. If you are developing a system to calculate the current weather conditions, you might depend on a library that provides functions to calculate the wind speed and its direction. If you are building a web site, you'll likely use a framework designed to serve web sites.

If you are working on a complex system, you might require hundreds of external libraries in an application. The primary use of a repository manager is to proxy and cache packages from "external" repositories. Your organization uses open source libraries, and when your application build needs them, it will automatically query a local repository manager. If that local repository manager does not have that particular package, it will retrieve from an external repository server and cache it for later use. (Think of how a librarian works. Ask a librarian for a rare book. If he doesn't have it, he will likely call up another library and have the book sent over).

Repository Setup

Note: we are using a nexus repository as an internal npm registry, do not confuse it with a source control management system(Github)! This repository holds our published packages, not their source code!

  1. Download Nexus directly from here or pull it from Dockerhub, and build the image.
  2. Log in to your Nexus server, and click on ‘Create repository’ Button.

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

  1. npm hosted/private:- A repository for NPM packages that your team develops.
  2. npm proxy:- A repository that proxies everything you download from the official NPM registry.
  3. npm group:- This will group all of the above repos and provide you a single URL to configure your clients to download from/deploy to.

First, create a new npm proxy repository:

  • Set the “Name” field 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.

Now, we’ll define the internal npm repository:

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

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

  • Create a new npm group repository.
  • Set the “Name” field 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 Configuration

Once we are done with Nexus repository configuration, all that is left to do is to configure our local NPM to work against this private NPM registry.

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

registry=http:///repository/npm-all/
_auth=
email=

 

In our case, it would be like:

1

As Nexus supports HTTP Basic Access Authentication, an auth token is nothing but a Base64 encoding of username and password which can be obtained by executing the following command:

echo -n ‘<nexus_user_name>:<nexus_user_password>’ | openssl base64

Also, In your package.json, add the following entry:

"publishConfig": {

“registry”: “http:///repository/npm-internal/"

}

Notice that in .npmrc, the registry is pointing to npm-all while in package.json it is pointing to npm-internal.It is because each “npm install” command will first check the package inside npm-all which is a group of both npm-proxy and npm-internal.  If the requested package is already available in any of the repos, it will fetch that package immediately. Otherwise, the new package will be downloaded from the external global npm registry (using our proxy repository) and will be served to the client.

While npm publish uses package.json, the publish config publishes the package directly to the internal repository, npm-internal.

I hope this article helped you understand the basics of Nexus Repository Manager and how it can help us preserve build stability and protect important IP assets at the same time, enjoying all the benefits of NPM global community. Also, Nexus Repository Manager offers great support to Maven, Gradle, Ruby Gems, Pip and Go package management as well.

Share :