This article mainly records some experience accumulated in NPM practice. In addition to understanding the documents, it also adds some usage scenarios, mainly involving the following aspects

  1. Specify the installation source installation

  2. Install via the Github branch

  3. How do I debug packages locally?

  4. More package management

  5. lerna

  6. After the NPM CLI tool is installed, how can I let the system find the command?

  7. What files will be uploaded in your NPM package?

  8. Which file entry is loaded with the NPM package?

  9. How do you keep your packages from creating redundant dependencies?

Package installation

While you are familiar with the usual ways to install packages, there are other ways to install packages that are particularly useful in addition to using the official NPM source.

Specify the installation source installation

There are usually two situations in which you need to specify the installation source. For example, if the company builds a private image internally, you need to specify the installation source. In addition, due to the slow speed of accessing the official NPM in China, third-party sources are used to improve the installation speed of package.

Specify the installation source by specifying the –registry parameter to the NPM command

npm install xxx --registry=https://maven.xxx.com.cn/repository/npmjs/
Copy the code

Install via the Github branch

When using the Github open source library, it is inevitable that the maintenance of the open source library will not be timely, and the bugs will affect the online experience. When you submit the fix PR, they will not be dealt with in a timely manner. Therefore, in order to fix the online problems quickly, We can temporarily switch the package dependency to our own github fix branch and then switch back after the PR process.

Eg: Install the github ant-design feature branch

npm install ant-design/ant-design#feature
Copy the code

More and more

You can run the NPM install -h command to learn more about installation methods.

npm install (with no args, in package dir)
npm install [<@scope>/]<pkg>
npm install [<@scope>/]<pkg>@<tag>
npm install [<@scope>/]<pkg>@<version>
npm install [<@scope>/]<pkg>@<version range>
npm install <alias>@npm:<name>
npm install <folder>
npm install <tarball file>
npm install <tarball url>
npm install <git:// url>
npm install <github username>/<github project>
Copy the code

Package development

I believe many of you have experience in package development. A quick review of the process

  • Register an NPMJS account

  • Use the NPM scaffold command NPM init to complete package initialization

  • Develop code and build

  • Go to NPM Login and publish NPM Publish

How do I debug packages locally?

In front end development, it is common to extract common logic from a project and publish a separate NPM library for interoperability in other projects. So how do you test and validate the library during development, NPM publish and install each change into the business application and then test and verify it? This is obviously very inefficient.

Usually we use the NPM Link soft link. For example, we extract the commonLogic library from the business, link commonLogic in the business application, and then modify commonLogic. The commonLogic in node_modules of the business application that references the library will be updated synchronically.

Steps:

1. Link commonLogic to the global interface

NPM install commonLogic -g NPM linkCopy the code

2. Create a Soft link for commonLogic in the service application

# Execute from node_modules link commonLogic to NPM Link commonLogicCopy the code

More package management

Package size is an important indicator, and things like React are unpacked by function, allowing users to install as needed to reduce build size. Therefore, when the library is complex enough to be large, it needs to be unpackaged, commonly known as mono-repo.

The first thing you need to understand is the concept of workspaces, which are unpackaged collections of subpackages that allow you to manage multiple subpackages in your local file system from a root package and link automatically during the NPM install phase, instead of manually linking interdependent subpackages in your local file system. If you need to set private to true to enable workspaces, the root directory of multiple packages does not need to be published, and setting private prevents accidental publishing.

More convenient multi-package management tools

Lerna is a tool that optimizes the multi-package management process by helping us unify the installation and build, remove subpackage dependencies, run all subpackage unit tests, and so on, simplifying the package management process.

Lerna common functions:

1. Initial LERNA

Run NPX Lerna init to generate lerna.json. You can configure lerna by yourself

2. Install subpackage dependencies uniformly

Run lerna bootstrap to install dependencies for each subpackage. Subpackages that have dependencies are automatically linked due to the workspaces feature of package management tools such as NPM and YARN. However, you need to install your own dependencies for the package.json configuration in the root directory.

3. Clear all subpackage dependencies

Running lerna Clean removes all subpackages’ node_modules, as well as the root configuration dependencies.

4. Run test cases

Lerna Run test executes the test script for each subpackage. If you need to execute test cases for only one subpackage, you can specify subpackages by running something like lerna Run test –scope=@scope/minirepo.

After the NPM CLI tool is installed, how can I let the system find the command?

You can configure the bin field in package.json, which defines the entry to the executable file, using {command name: If you install the tool package globally, you will soft link the bin declared files to /usr/local/bin/xx-cli, but note that you need to use the bin script to reference files with #! /usr/bin/env Starts with node. Make sure the script starts with node.

What files will be uploaded in your NPM package?

The files field in package.json is an array of file re that describes the entire entry of the package when it is installed as a dependency. It defaults to [“*”], which means it will contain all files.

Some files will be included or excluded whether you configure them in the files array or not. Files like.npmignore and node_modules will be excluded, but package.json and README will always be included.

The.npmignore file will also affect it, and entries defined in that file will be excluded. If there is a.gitignore file and there is no.npmignore, the.gitignore file will replace the.npmignore file.

Which file entry is loaded with the NPM package?

The common module specifications we use include ESM and CommonJS. The specific file entry to load has a priority depending on the module specification you are using, the environment you are using, and the entry defined by NPM. Therefore, multiple entry files can be defined to be compatible with different environments and different module specifications.

These three fields in package.json define the entry (in descending order of priority)

  1. Main: entry file, which can be used by browser and node environments

  2. Module: the ESM entry file, which can be used by browser and node environments

  3. Browser: the browser environment entry file

How do you keep your packages from creating redundant dependencies?

For example, react component libraries such as Ant-Design must depend on React. Would it be a problem if the React version that Ant-Design relies on is not the same as the react version in your project? It’s not a big deal, except that there are redundant dependencies that make the bundle bigger.

The early dependency management strategy of NPM was to build dependency trees according to the dependency nesting structure, which resulted in a very deep hierarchy of dependency trees and the downloading of a large number of duplicate package resources. After NPM V3, tile the dependency tree as much as possible for shared use.

In the example above, if ant-design uses dependencies definition, if react versions are not consistent with each other, the react tree strategy will continue to be used in Ant-Design because other versions of React already exist. It generates the following structure.

Project ├── node_modules ├── react@v1 ├─ antd ├── node_modules ├── react@v2Copy the code

In fact, you can see that Ant-Design uses peerDependencies.

  1. If the same dependency has already been installed, and the version range specified by peerDependencies contains the version on which the dependency exists, the version defined by peerDependencies will not be installed again.

  2. If the version range specified by peerDependencies does not contain a dependent version, it will be downloaded and installed according to the nested dependency tree policy, but it will be warned that you should fix the version to make it compatible.

  3. If the package specified by peerDependencies has not already been installed, the dependency is directly tiled.