• What is NPM? In this Tutorial, Beginners are required to study NPM for Beginners.
  • Written by Stanley Nguyen
  • Translator: @Moon White

This article serves as a basic guide to NPM, Node.js’s favorite companion.

Node.js has been taking the world by storm since 2009. Hundreds of thousands of systems have been built on Node.js, prompting developers to proclaim in the community that “JavaScript is eating software.”

One of the main factors behind Node’s success is its popular package manager, NPM, which enables JavaScript developers to quickly and easily share useful packages such as Lodash and Moment.

As I write this, NPM has helped release 1.3 million packages, with more than 16 billion downloads per week! These numbers are very useful for any software tool. So now let’s talk about what NPM really is.

What is NPM

NPM (” Node Package Manager “) is the default package manager for JavaScript runtime Node.js.

It’s also known as “Ninja Pumpkin Mutants,” “Nonprofit Pizza Makers,” and many other random names that you can explore on NPM-Expansions.

NPM consists of two main components:

  • A CLI (command line interface) tool for publishing and downloading packages
  • An online repository that hosts JavaScript packages

For a more intuitive explanation, we can think of the repository nPMjs.com as a logistics hub that receives packages of goods from the seller (the author of the NPM package) and distributes these goods to the buyer (the user of the NPM package).

To facilitate this process, the NPMJs.com Logistics Hub employs a team of hardworking wombats (NPM CLI) who will be assigned to each NPMJs.com user as personal assistants. Therefore, dependencies are passed to the JavaScript developer as follows:

The process for releasing THE JS software package is as follows:

Let’s take a look at how wombat can assist developers who want to use JavaScript packages in their projects. We’ll also see how they (NPM CLI) help open source wizards bring their great libraries to the world.

package.json

Every JavaScript project (whether node.js or browser application) can be treated as an NPM package, and the project and package information can be described through package.json.

We can think of package.json as shipping information on a delivery box.

When a JavaScript/Node.js project is initialized by running NPM init, a package.json file is generated with the contents (basic metadata) provided by the developer:

  • name: The name of the JavaScript project or library
  • version: Project version. The version of the project. In general, this area is often overlooked in application development because there is clearly no need for versioning open source libraries. However, it is still convenient to use as a source for deployment versions.
  • description: Project description
  • license: Project license

npm scripts

Package. json also supports a scripts property, which can be used as a command-line tool to run locally in your project. For example, the scripts section of an NPM project might look like this:

{
    "scripts": {
        "build": "tsc"."format": "prettier --write **/*.ts"."format-check": "prettier --check **/*.ts"."lint": "eslint src/**/*.ts"."pack": "ncc build"."test": "jest"."all": "npm run build && npm run format && npm run lint && npm run pack && npm test"}}Copy the code

Where esLint, prettier, NCC, jest are not necessarily installed as global executables, they can also be installed locally in the project node_modules/.bin/.

The newly introduced NPX allows us to run these node_modules project scope commands as if they were global installers by prefixing them with NPX… NPX prettier –write ** / * Ts).

dependencies vs devDependencies

These two come in the form of key-value objects, where the name of the NPM library is key and the semantically formatted version is value. Take a look at Github’s TypeScript action template for an example:

{
    "dependencies": {
        "@actions/core": ^ "1.2.3"."@actions/github": "^ 2.1.1"
    },
    "devDependencies": {
        "@types/jest": "^ 25.1.4"."@types/node": "^ 13.9.0"."@typescript-eslint/parser": "^ 2.22.0"."@zeit/ncc": "^ 0.21.1"."eslint": "^ 6.8.0"."eslint-plugin-github": "^ 3.4.1 track"."eslint-plugin-jest": "^ 23.8.2"."jest": "^ 25.1.0"."jest-circus": "^ 25.1.0"."js-yaml": "^ 3.13.1"."prettier": "^ 1.19.1"."ts-jest": "^ 25.2.1"."typescript": "^ 3.8.3"}}Copy the code

These dependencies are installed through the NPM install command with the –save or –save-dev flags. They are used in production and development/test environments respectively. In the next section, we’ll take a closer look at installing these packages.

Also, it’s important to understand the notations that precede the semantic version (assuming you’ve read Semver’s Major.minor.patch model) :

  • ^: The latest minor version. For example, if^ 1.0.4A specification is a version1The latest minor version of a series, the version may be installed1.3.0.
  • ~: Indicates the latest patch version. With minor versions in^Same, if~ 1.0.4Specification is1.0The latest minor version in a series, the version may be installed1.0.7.

All of these exact package versions are recorded in the package-lock.json file.

package-lock.json

This file describes the exact version of the dependency used in the NPM JavaScript project. If package.json is a generic descriptive tag, package-lock.json is a component list.

Just as we don’t normally read ingredient lists on food packages (unless you’re bored or need to know), package-lock.json isn’t meant to be read line by line by developers (unless we’re desperate to solve the “work on my machine” problem).

Package-lock. json is typically generated by the NPM install command and can also be read by our NPM CLI tool to ensure that the build environment of the project is reproduced using the NPM CI.

How can I use NPM effectively as a user

From the 16 billion downloads out of the 1.3 million packages released mentioned earlier, it can be inferred that the majority of NPM users are using NPM in this direction.

npm install

This is the most common command we use today when developing JavaScript/Node.js applications.

By default, NPM install will install the latest version of the package with the ^ version number. NPM Install in the context of the NPM project will upgrade the package (and regenerate package-lock.json) by downloading the package to the node_modules folder of the project according to the package.json specification. NPM install can match based on ^ and ~ versions.

If you want to install a package in a global context that can be used anywhere on the machine, you can specify the global flag -g (for example, live-server).

NPM makes it so easy to install JavaScript packages that this command is often used incorrectly. This led some programmers to joke about NPM:

However, NPM packages that are too big and too deep can be saved with the Production flag! In the previous section, we discussed Dependencies and devDependencies for production and development/test environments, respectively. How the –production flag is distinguished in node_modules.

By attaching this flag to the NPM install command, we will install the package only from Dependencies, greatly reducing the size of node_modules to the size necessary for the application to function properly. DevDependencies should not be introduced into production!

npm ci

So, if NPM install –production is the best option for a production environment, must there be an option that works best for a local, test environment?

The answer is NPM CI.

Just as package_lock.json is generated whenever NPM Install is called if it does not already exist in the project, NPM CI consumes this file to download the exact version of each package the project depends on. .

This way, whether it’s a laptop for local development or a CI (Continuous integration) build environment such as Github Actions, we can ensure that the project context remains exactly the same across different machines.

npm audit

As more packages are released and are easy to install, NPM packages are vulnerable to malicious attacks by malicious authors, such as these.

Aware of problems with the ecosystem, the NPm.js organization came up with the idea of NPM Audit. They maintain a list of security vulnerabilities that developers can audit for dependencies in their projects using the NPM audit command.

NPM Audit provides developers with information about vulnerabilities and whether there is a version to fix. For example,

If the remedy is available in the next continuous version upgrade, the NPM Audit Fix can be used to automatically upgrade the version of the affected dependencies.

How can I use NPM effectively as a writer

We’ve seen how to use NPM effectively as a user through the NPM CLI, but what about using 🥳 as an author?

npm publish

Sending packages to nPMjs.com is easy because we just need to run NPM Publish. The tricky part (not specifically for NPM package authors) is determining the version of the package.

According to Semver.org’s rule of thumb:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR when adding features in a backward compatible manner, and
  3. PATCH version for backward-compatible bug fixes.

It is especially important to follow these rules when distributing packages to ensure that you are not breaking anyone’s code, since the default version matched in NPM is ^ (also known as the next minor version).

❤️ npm ❤️ JavaScript ❤️ Node.js ❤️

That’s all we need to start using NPM effectively and commanding our lovely wombat army!