The closing words come first.

I sometimes come to the conclusion that commands or tools THAT I don’t use very often are there to solve problems that bosses have!

We deal with NPM every day, but many of us (including me, of course) still have a rudimentary grasp of NPM. For example, NPM init @vitejs/app is used to create a package.json file.

Also, NPX create-react-app my-app command.

Indeed, there is some logic behind these commands that we rarely pay attention to, which is not difficult, but we have no system to understand.

Considering all these, I have been systematically studying NPM recently. The main learning method is to use some spare time and combine my previous experience in using NPM to check out some knowledge blind spots and doubts from the official DOCUMENTS of NPM. After reading down the official documents one by one and reviewing and verifying the unclear knowledge points, I have gained more understanding of NPM, although I have hardly used a small part of knowledge points. Finally, I simply recorded some of my learning in the form of mind mapping.

After these days of study, I found that the two general directions of my study of NPM are NPM CLI and package.json.

Today I want to talk about the NPM CLI, which stands for Command Line Interface. NPM provides many CLI commands. For details, see NPM CLI Commands.

Usage: npm <command> where <command> is one of: access, adduser, audit, bin, bugs, c, cache, ci, cit, clean-install, clean-install-test, completion, config, create, ddp, dedupe, deprecate, dist-tag, docs, doctor, edit, explore, fund, get, help, help-search, hook, i, init, install, install-ci-test, install-test, it, link, list, ln, login, logout, ls, org, outdated, owner, pack, ping, prefix, profile, prune, publish, rb, rebuild, repo, restart, root, run, run-script, s, se, search, set, shrinkwrap, star, stars, start, stop, t, team, test, token, tst, un, uninstall, unpublish, unstar, up, update, v, version, view, whoami npm <command> -h quick help on <command> npm -l display full usage info npm help <term> search for help on <term>  npm help npm involved overview Specify configs in the ini-formatted file: C:\Users\Tusi\.npmrc or on the command line via: npm <command> --key value Config info can be viewed via: npm help configCopy the code

There are too many commands to explain them all. I’ve narrowed it down to a few basic commands that I’ve seen a lot.

NPM Common CLI commands

npm help

Ask if you don’t understand. NPM help is a good command. Just as I use git –help, I always use help to look up some obscure commands.

npm init

NPM init is used when we initialize an NPM package, or create a package.json file.

npm init xxx

Although I used NPM init XXX when creating vue or React applications, I didn’t pay much attention to what was going on behind the scenes with NPM init XXX.

For example, NPM init@vitejs /app is used to create applications, but it’s not always possible to realize that it’s called npx@vitejs /create-app, which is actually executing a create-app script.

This means that if you want someone to call your package with the NPM init XXX command, you must provide a create-xxx script.

npx

NPX is a command used to run local or remote NPM packages. Such as the NPX @vitejs/create-app mentioned earlier.

If the package requested by NPX (such as @vitejs/create-app) does not appear in the local project dependencies, NPM installs @vitejs/create-app in the global NPM cache directory.

The create-app script is then executed, and this script needs to be defined under the bin configuration of package.json.

NPM init XXX and NPX create-xxx are also common CLI tools.

npm config

NPM config is used to manage configuration files. We usually use the NPM source.

npm config set registry https://registry.npm.taobao.org 
Copy the code

Using NPM config List, we can list all configuration items; Get, set, and delete can be used to query, set, and delete configuration items.

npm install / uninstall

NPM install installs dependencies listed in package.json into node_modules when no package is specified, or installs the specified package if the package name is specified. Main notes:

  • -g is the global installation.

  • If –production is specified, or NODE_ENV is production, the dependencies in devDependencies are not installed.

  • –save equals -s to save dependencies in package.json. These dependencies (e.g. Vue, React) are bundled into a Bundler (e.g. Webpack) Dependency Graph. NPM install vue executes -s behavior by default, but it is recommended to display -s for clarity.

  • –save-dev is equivalent to -d. The installed dependencies are stored in devDependencies. These dependencies are usually the tools of the development environment, such as ESLint, webpack, Babel, etc. These dependencies are not handled by the packaging tools in the build result.

However, if you install the VUE using NPM install -d vue and reference the VUE dependencies in your project, the WebPack Dependency Graph will also have the VUE, and the vUE will eventually show up in the build result.

Look at this, are you confused again? Whether NPM install -s vue or NPM install -d vue, if the project references vue, the vue will be packaged into the build result, so what is the difference between -s and -d?

Note that Webpack does not care whether a Dependency is Dependencies or devDependencies, as soon as it goes to WebPack’s Dependency Graph, it is packaged into the result.

So don’t be fooled by the build tools, -s and -d affect NPM install, and only in limited scenarios.

If someone installs your package package-a, they will install the dependencies in package-a and not the devDependencies in package-a.

From two aspects:

  • The first case: production dependency strays into development dependency.

Suppose your package package-a provides an ESM entry via the Module field of package.json.

"module": "module-entry.js"
Copy the code

It relies on another package in module-entry.js, let’s say lodash-es.

// module-entry.js
import { cloneDeep } from "lodash-es"
Copy the code

However, you did not notice that you installed via NPM install -d lodash-es, and you debug package-a locally without any problems. So you publish package-a, and your colleague Wang installs package-a, but finds it wrong (because he does not automatically install devDependencies of package-a).

  • The second case: development dependency strays into production dependency.

Development environment dependencies move into production, leading to more meaningless development dependencies at build time and larger packaging results, often when developing libraries or components.

import VueAwesomeProgress from "./index.vue";

// Unnecessary vUE is introduced when developing components;
// Causes the final build file to become larger.
import Vue from "vue"
console.log(Vue)

VueAwesomeProgress.install = function(Vue) {
    Vue.component(VueAwesomeProgress.name, VueAwesomeProgress);
};

if (typeof window! = ='undefined' && window.Vue) {
    window.Vue.use(VueAwesomeProgress)
}

export default VueAwesomeProgress
Copy the code

Essentially, when we develop a Vue component, we only need to refer to Vue as devDependencies.

npm start

NPM start is a semantic command. Usually we will customize the start script in scripts, such as:

"start": "npm run dev"
Copy the code

If no custom start script is specified, NPM start executes by default:

node server.js
Copy the code

npm run

NPM run is used to run the scripts we defined, just following the script name. When NPM run is run, we can call executables or scripts in special paths, including the PATH defined by the environment variable PATH, as well as./bin in the current project node_modules.

In addition to the shell’s pre-existing PATH, npm run adds node_modules/.bin to the PATH provided to scripts.

npm version

This command is also worth knowing, semantically, because NPM version modifies the version field in package.json to manage the package version number.

You can try running:

npm version major/minor/patch -m "reason for upgrade"
Copy the code

Major, Minor, or Patch indicates the major version, minor version, or patch version. Of course, you can also pass other version parameters, see npm-version.

Usually, we also define a custom version script to automatically generate Changelog.md in conjunction with Conventional changelog.

{
  "scripts": {
    "version": "conventional-changelog -p angular -i CHANGELOG.md -s && git add CHANGELOG.md"}}Copy the code

Contract related

npm login/ npm adduser

The process of releasing an NPM package is not complicated. First you must login to NPM from the command line, using NPM adduser, alias NPM login.

Make sure you have the right representation

Sometimes, considering the domestic environment, when we install dependencies, we will set the source of NPM as Taobao mirror. But before the NPM package can be published, the source must be cut back to NPM.

npm config set registry http://registry.npmjs.org/
Copy the code

npm publish

Release an NPM package. Release boundaries are version-determined and cannot release the same version. Even if you change only one README, you must change version to re-nPM publish.

npm unpublish

The equivalent of sending a package is to remove a published package. You can choose to remove an entire released package, or you can remove a specific release.

npm pack

Package package into TGZ format. For example, in the vue-awesome-progress directory, running the NPM Pack yields a vue-awesome-progress-1.9.1.tgz, where 1.9.1 is taken from the Version field.

TGZ installs vuE-awesome -progress and its dependencies in the node_moudles directory of the current directory by installing vue-awesome-progress-1.9.1. TGZ.

npm link

NPM link is used to create a symbolic link, similar to the effect of Linux soft links (ln -S).

First you need to run NPM Link under the package directory where the link is to be created (such as vue-awe-progress), which creates a Symlink under the NPM global folder.

NPM prefix -g points to the NPM global folder and I have the value here:

PS C:\Users\Tusi> npm prefix -g
C:\Users\Tusi\AppData\Roaming\npm
Copy the code

NPM link, C: Users\Tusi\AppData\ modules\ Folder \ NPM \node_modules\ folder \ NPM \ node_Modules \ Folder \Users\Tusi\AppData\Roaming\ NPM \node_modules\ Folder \

At the same time, if there is a configuration bin file in vue-awesome-progress, it will also be linked to the global.

Where vue-awesome-progress is used, you can install it via NPM link vue-awesome-progress. It will also be installed in node_modules, but it’s a full vue-awesome-progress, Instead of vue-awesome-progress after NPM publish.

In my view, NPM link is suitable for debugging two or more packages locally, so that you do not have to re-nPM run build, NPM publish, save a lot of things.

Written in the end

When we get used to a tool’s common functionality, we rarely think about what’s going on behind it, and even less about what else it can do. But then, after you’ve had some experience with it, you dig into it and you’re like, “Oh my God! So this order is to solve the problem, the bosses really thought it all out!”

As I said at the beginning, if one wants to advance in the field of technology, one must ask enough questions for oneself and go deeper with them. As for how to go deeper with questions, I think it’s best to create your own product, be it a project, a component, a Library, or even a framework. When you’re confused, you’ll be pleasantly surprised to find leaders offering solutions. If not, you become the boss!

If you think this article is good, please like it and follow it. Thank you for your support. Welcome to communicate with me directly. My name is Tusi. I look forward to making progress together with you!