Before talking about the how with NPM packages, let's talk about the why. Why publish private NPM packages to Nexus?
There are any number of motivations, and those include following the DRY principle, sharing code within an organization, and keeping code secure. It's just good software development practice.
So, now that we understand the why, what about the how? How can you publish NPM packages?
First of all, you have the ability to do it with privately hosted external servers, such as NPM organizations. Or you can use internal hosted solutions, such as maintaining your own private Nexus Repository, which gives you a lot of flexibility.
If you go the Nexus route, how exactly does this work? Here's a diagram:
Nexus sits in the middle, between the client and the external NPM repository. From there, it provides a group repository that synthesizes information between the proxy repository and the hosted repository—a mix of public and private package data.
To actually get started, you pull the Docker image and run it on a local machine. The advantage of doing it this way is that if you have to restart your server, you won't lose user information or any other data.
When you do this, here’s your current state:
You have the Nexus server running and you've mounted a volume to it for internal data.
Next up, you'll want to create an admin user. Make sure that you don't continue using default credentials! Once the user is created, disable anonymous access as well, getting your security off on the right foot.
With that in place, you'll have to decide where you want to keep the private repositories that you create. You could put it in a filesystem or use S3. Kashyap recommends using S3 to have less data to worry about, and doing that requires an access key and a secret.
Next up, you'll create a hosted repository to communicate with your S3 bucket. Give it a name and select the Blob store with which it will communicate.
Having done that, let's check in on our current state of affairs, progressing toward the end state. As you can see, we've now added the hosted repository, synced with internal data.
Having done that, let's check in on our current state of affairs, progressing toward the end state. As you can see, we've now added the hosted repository, synced with internal data.
The internal data doesn't just contain the binaries, either. It contains configuration information around roles.
To continue the journey, it's time to create a proxy repository. Why do this? Why not just reach out directly to the public NPM repo? Well, if you do that, you'll have to figure out whether it exists in your private repo or in the public one, and you have to manage those checks. The Nexus repo gives you the ability to combine public and private requests into a group and make it seamless and transparent. It also serves to cache the public requests and reduce the communication with the broader internet.
Creating the proxy is straightforward. You can just fill out a simple form within Nexus and have the proxy information stored. This gets us near to completion:
Now it's time to set up the group repository to encompass the proxy and private repos. This setup process is similarly simple, and you do it by using the form to add the proxy and private repositories to the group.
That gives us the following:
Now, we just need to set up a realm to control how we push data into this environment. This requires enabling the NPM bearer token realm, which, in turn, enables the publishing of packages.
With this, we've completed the puzzle and are ready to start pushing private packages. You will now be able to publish packages to the private repository.
Getting it to the server, however, isn't the end. You also want to be able to manage it and allow retrieval. This is just a question of granting read only access to the users who will become consumers of your repository.
And, that brings us to the ultimate goal, pictured above: a sophisticated way to publish and manage private packages.
You can view the full session and dive further into publishing NPM packages below: