preface

Private NPM libraries, I think, are a phase that every team practices and goes through. There are many ways to implement private NPM, such as based on private Git repositories, based on NPM’s official private functionality (paid for), Verdaccio, and so on. But all things considered (free and easy to use), Verdaccio is slightly better than both.

In this article, we will use Verdaccio to build an enterprise-class private NPM library!

I. Installation and startup

The installation and startup process for Verdaccio is simple. The first is to install Verdaccio globally:

npm i -g verdaccio

Then, start verdaccio by typing the verdaccio command in the terminal:

verdaccio

Verdaccio then prints a prompt on the terminal, with its configuration file location, the address of the service it started, and so on:

By default, Verdaccio starts the service on port 4873. If you open this address in your browser, you will see the interface of the private library NPM built by Verdaccio:

As you can see, the default interface style is simple and elegant. Also, we are prompted with the commands we need to execute to log in and publish the NPM package.

II. Configuration modification

Verdaccio is installed and started, though. However, since the default configuration of Verdaccio is not consistent with our production requirements, we need to modify the configuration of Verdaccio.

In a production environment, private NPM libraries require the following three functions:

  • Supports searching for NPM packages
  • Access to the NPM package is restricted to registered users only. And in some cases, users need to be deleted
  • After the NPM package is published, it is pushed to the pin group to tell which NPM package has been published

The Verdaccio configuration file is the config.yaml file in the ~/.config/Verdaccio folder. The default configuration will look like this:

storage: ./storage
plugins: ./plugins
web:
  title: Verdaccio
auth:
  htpasswd:
    file: ./htpasswd
uplinks:
  npmjs:
    url: https://registry.npmjs.org/
packages:
  '@*/*':
    access: $all
    publish: $authenticated
    unpublish: $authenticated
    proxy: npmjs
  '**':
    access: $all
    publish: $authenticated
    unpublish: $authenticated
    proxy: npmjs
server:
  keepAliveTimeout: 60
middlewares:
  audit:
    enabled: true
logs:
  - { type: stdout, format: pretty, level: http }

Here’s a look at some of the values in the default configuration:

  • storageThe location where the published packages are stored, by default, at~/.config/Verdaccio/folder
  • pluginsThe directory where the plug-in resides
  • webInterface related configuration
  • authUser related, such as registration, authentication plug-in (default is usedhtpasswd)
  • uplinksUsed to provide access to external packages, such as NPM, CNPM corresponding sources
  • packagesPermissions to configure publishing packages, delete packages, and view packages
  • serverPrivate repository server-side configuration
  • middlewaresMiddleware-related configurations are introduced by defaultauitMiddleware to supportnpm auditThe command
  • logsConfiguration of terminal output information

Next, let’s modify the values in the Verdaccio configuration file to support these functions.

2.1 Start Search

When we have many packages in our private NPM inventory, we have trouble finding a particular package. Verdaccio supports search. It is controlled by search and is false by default, so we need to enable it here:

search: true

Once enabled, we can conduct normal searches in the search bar on the page of the private NPM library.

2.2 Permission control

Permission control refers to the fact that we need the packages published on the private NPM library to be viewed only by team members, and not by anyone else. So, back to Verdaccio, we need to do these two things:

  • Restricts viewing of NPM packages to registered users only
  • Disallow user registration (after team members have registered)

Accordingly, here we need to modify the configuration file’s pacakges and auth. Packages are used to configure publishing packages, view packages, and remove permissions associated with packages. Let’s first look at the default configuration:

packages:
  '@*/*':
    access: $all
    publish: $authenticated
    unpublish: $authenticated
    proxy: npmjs
  '**':
    access: $all
    publish: $authenticated
    unpublish: $authenticated
    proxy: npmjs

The key here represents the package name that the corresponding permissions need to match. For example, for the first one, if we publish a package name like @wjc/test it will hit. There are four parameters in each rule. The proxy represents if in private library of NPM could not find, will be the agent to NPMJS corresponding unlinks the NPMJS (https://registry.npmjs.org/). The remaining three parameters, which are used to set the permissions associated with the package, have three optional values of $all, $anonymous, and $authenticated. So, let’s take a look at what these three parameters mean:

  • accessControls access to packages
  • publishControls the publishing rights of the package
  • unpublishControl the delete permissions of the package

Obviously, what we need here is that only the user can have the above three permissions, which are all set to $authenticated:

packages:
  '@*/*':
    access: $authenticated
    publish: $authenticated
    unpublish: $authenticated
    proxy: npmjs
  '**':
    access: $authenticated
    publish: $authenticated
    unpublish: $authenticated
    proxy: npmjs

After setting packages, we also need to change the value of auth because there is no limit to the number of registered users. This means that if your private NPM library is deployed in an external environment, anyone can register users with the NPM adduser command.

Obviously, this is not allowed, so here we need to set the max_users of auth to -1, which means to disable registered users:

auth:
  max_users: -1

To enable user registration, set the specified number (greater than 0)

2.3 Release package push pin group

Packing push group means that every time we publish a package, the robot in the group can notify us about the published package.

First of all, here we need to have a Webhook corresponding to the bots of the pegging group (access method can view the pegging document). Then add notify to the Verdaccio configuration file:

notify: 'dingtalk': method: POST headers: [{'Content-Type': 'application/json;charset=utf-8'}] endpoint: https://oapi.dingtalk.com/robot/send?access_token= * * * *, # of nailing robot webhook content: '{" color ":" green ", "message" : "new package issued: * {{ name }}*","notify":true,"message_format":"text"}'

Method and headers represent the method and entity type of the request, respectively. The endpoint represents the Webhook address of the request. Content represents the basic template for getting published information, in which the value of message would be the content of the message sent by the bots in the group (name represents the name of the published package).

Suppose we publish a private package called verdaccio-npm-demo, and we receive a notification in the Pin Group:

Three, basic use

Now that Verdaccio is configured. Then we can start releasing our first private package 😎.

3.1 Registered Users

First, we need to register a user:

npm adduser --registry http://localhost:4873/

It will then ask you for a username, password, and email address to log in to the private NPM library:

3.2 Delete User

Since we have registered users, the inevitable requirement is that in some scenario, we need to remove a user to prevent him from logging into the private NPM library.

As mentioned earlier, Verdaccio uses htpasswd by default for authentication. Accordingly, the registered user information will be stored in the ~ /. Config/verdaccio/htpasswd file:

Wuliu: w5v1i pWxgur / 1: autocreated T07:2021-02-18 58:57. 827 z

Here a record corresponds to a user, that is, if the record is deleted, then the user can not log in, that is, the user has been deleted.

3.3 Add and switch sources

Here we switch sources via NRM for operational purposes. If you don’t have NRM installed, you can install it first:

npm i -g nrm

Then, add a source using NRM:

nrm add mynpm http://localhostm:4873/

MyNPM here stands for your source for short, and you can name it whatever you like.

Next, we can run the NRM ls command to see the existing source:

You can see by default using the source of NPM is https://registry.npmjs.org/, so here we need to switch it into private NPM corresponding to the source:

nrm use mynpm

After good source switch, we after NPM I will go to the private library search packet, if there is no will go to https://registry.npmjs.org/ (because the proxy configuration above) to find the package.

3.4 release

Publish directly under the root of the project that needs to publish the package (let’s say our package is called verdaccio-npm-demo2 in this case) :

npm publish

Then, in the interface of the private NPM library, we can see our published package:

conclusion

Of course, Verdaccio can do a lot more, such as integrate Git Action automatic package, custom authentication plug-in, and so on. However, after a lot of work, the private NPM library is starting to take shape and is ready for production 😲. In the end, if there is any improper expression or mistake in the article, please raise your Issue.

Thumb up 👍

If you get anything from reading this article, you can like it. It will be my motivation to keep sharing. Thank you

I am Wu Liu, like innovation, tinkering with source code, focus on source code (VUE 3, VET), front-end engineering, cross-end technology learning and sharing. In addition, all my articles will be included in
https://github.com/WJCHumble/Blog, welcome Watch Or Star!