Publishing npm Packages

Before now, our main focus has been to learn everything about improving and contributing to existing projects, but quite often, this is not everything. Some projects will need to be initiated correctly by you and one part of this process is to decide which packages should actually be reused.

We’ve already learned that reusability in Node.js is primarily gained through the module system, which can be enhanced by third-party dependencies in the form of npm packages. In this chapter, you’ll learn how you can publish npm packages yourself. This way, a functionality implemented once can be shared among the team working on the same project or with anyone.

To achieve our goal in this chapter, first, we’ll set up a simple library to serve our case well. Then, we publish this library to the official npm registry in a way that makes the code available to any Node.js developer. If you want to keep your library a bit less exposed, then the following...

Technical requirements

The complete source code for this chapter is available at https://github.com/PacktPublishing/Modern-Frontend-Development-with-Node.js/tree/main/Chapter08.

The CiA videos for this chapter can be accessed at https://bit.ly/3UmhN4B.

Publishing to the official registry

Let’s start by creating a small library that uses a structure that can be seen very often in Node.js projects. The structure consists of an src folder, where the original sources are located, and a lib folder, containing the output to be used by the target system. The target system could either be something such as a bundler for browser applications or a specific version of Node.js.

To initialize this kind of project, we can use the npm command-line utility as we did before:

$ npm init -y

Now, we’ll set everything up. First, we will install esbuild as a development dependency. This can be very helpful for transforming our source files into usable library files:

$ npm install esbuild --save-dev

Next, we change package.json to fit our needs:

package.json

{
  "name": "lib-test-florian-rappl",
  "version": "1.0.0",
  "description": "...

Selecting another npm registry via .npmrc

To configure the behavior of npm, a special file called .npmrc is used. We’ve already briefly touched on this file in Chapter 3, Choosing a Package Manager. This file can be used not only to determine the source of the packages but also to define where to publish to.

A simple modification might look as follows:

.npmrc

; Lines starting with a semicolon or
# with a hash symbol are comments
registry=https://mycustomregistry.example.org

This way, all installations and publish attempts will be performed at https://mycustomregistry.example.org instead of the official registry located at https://registry.npmjs.org.

Quite often, this extreme approach is unnecessary or even unwanted. Instead, you might only want to use another registry for a subset of the packages. In the most common case, the subset is already defined by a scope.

Let’s say the @foo scope that we used in the previous section with the @foo/bar package...

Setting up Verdaccio

There are a couple of commercial registry options out there. Arguably, the most popular option is to get a pro plan for the official npm registry. This way, you’ll be able to publish and manage private packages. Whatever option you pick, you will always have to use a cloud version for publishing your packages.

Especially for playing around with the publishing process, having a registry locally would be great. A great option is to leverage Verdaccio for this. Verdaccio can be either run by cloning the Verdaccio code repository, running the Docker container provided by Verdaccio, or using npx.

Let’s go for the npx approach:

$ npx verdaccio

 warn --- config file  - ~/.config/verdaccio/config.yaml

 info --- plugin successfully loaded: verdaccio-htpasswd

 info --- plugin successfully loaded: verdaccio-audit

 warn --- http address - http://localhost:4873/ - verdaccio/5.14.0

Now that Verdaccio is running, you can go to the URL shown...

Writing isomorphic libraries

The holy grail of web development is the ability to write code not solely for the frontend or the backend but for both parts. Many frameworks and tools try to give us this capability.

To be accessible to multiple platforms, we not only need to ship multiple variants of our code but also only use APIs that are available on all supported platforms. For instance, if you want to make an HTTP request, then using fetch would be the right call for modern browsers. However, fetch was not available in less recent versions of Node.js. Therefore, you might need to solve this differently.

In the case of HTTP requests, there are already isomorphic libraries available – that is, libraries that will just do the right thing depending on the target runtime. You should only depend on these libraries.

Isomorphic fetch

The HTTP request problem can be solved in many ways – that is, by choosing an isomorphic library such as axios or isomorphic-fetch...

Publishing a cross-platform tool

Node.js would not be so powerful without its ecosystem. As we learned in Chapter 1, Learning the Internals of Node.js, relying on the power of its ecosystem was an elementary design decision. Here, npm takes the leading role by defining the package metadata in package.json, as well as the installation of packages.

During the installation of a package, a couple of things are happening. After the package has been downloaded, it will be copied to a target directory. For a local installation with npm, this is the node_modules folder. For a global installation with npm, the target will be globally available in your home directory. There is, however, one more thing to do. If the package contains a tool, then a reference to the tool will be put into a special directory, which is node_modules/.bin for a local installation.

If you go back to the code from the previous chapter, you will see that, for example, jest is available in node_modules/.bin. This...

Summary

In this chapter, you have learned about what it takes to publish a package to an npm registry – whether it is an official or private one. You also touched on a commonly used npm registry in the form of Verdaccio.

Equipped with the knowledge from this chapter, you should now be able to write reusable libraries that work in browser-based applications as well as in Node.js-based applications. You are also now capable of publishing tools that are based on Node.js. In a sense, these tools are just libraries with some additional fields in their associated package metadata.

In the next chapter, we will have a look at a different approach to structuring code – placing multiple packages in a single repository known as a monorepo.