By LeanCloud Weakish

Here are some practical tips for NPM package management tools that will slightly improve the quality of life for downfront and Node.js developers.

Most front-end and Node.js developers need NPM for their daily work. How do you feel about NPM? If you think NPM is great, check out this article for tips you may not have noticed before to make NPM work better. If you think NPM is bad, take a look at this article and you may find that with a few tricks, NPM can be made slightly less bad.

npm ci

Don’t be fooled by the name. NPM CI is not only suitable for continuous integration systems, it is very useful in daily development. Unlike NPM install, NPM CI installs dependencies based on package-lock.json, which ensures that the entire development team is using the same version of dependencies and avoids wasting time troubleshooting strange problems caused by inconsistent dependencies. Not only that, but NPM CI has a nice side effect of speeding up node module installation. Because NPM CI is installed directly based on the version specified in package-lock.json, it can greatly speed up node module installation in most cases without calculating dependency satisfaction issues. If you’ve ever switched to yarn, which is less compatible, or PNPM, which is less compatible, because NPM is too slow to install, try NPM CI.

In addition, if package-lock.json is obsolete (conflicting with package.json), the NPM CI will be nice enough to report an error, preventing project dependencies from becoming obsolete.

With NPM CI, I basically only use NPM Install when introducing new dependencies.

Note that NPM CI automatically clears existing node_modules before installation, so NPM CI naturally avoids inconsistencies and other issues that might arise with incremental installation. (This also means you have one less command to remember, NPM Prune.) If your network is slow, though, that might not be so great. Don’t panic, you can use –prefer-offline to make the most of NPM’s global cache to speed up the installation process.

Of course, since you’re using NPM CI, don’t forget to add package-lock.json to your Git repository.

npm outdated

NPM CI locks dependent versions based on package-lock.json to ensure consistency in the project development environment. But that doesn’t mean dependent versions are locked. Periodically, dependent releases need to be upgraded to take advantage of bug fixes, new features, and performance improvements. In this scenario, NPM outdated is recommended. It lists project dependencies that have not been upgraded to the current latest version. Red indicates compliance with the specified semantic version range and can theoretically be upgraded mindlessly (NPM update updates all red dependencies at once). Yellow indicates that the version does not conform to the specified semantic version range, such as large version upgrades, which may encounter compatibility issues.

Some projects are in the maintenance phase and no new features will be added, and even minor issues may not be fixed, but serious issues such as security vulnerabilities will still be addressed. You can use the NPM audit command to list the versions of the project dependencies that have security vulnerabilities. Projects in the active development phase certainly need to be concerned about security vulnerabilities, but because NPM Install automatically runs NPM Audit when new dependencies are introduced, and NPM Outdated runs regularly, there is not much opportunity to run NPM Audit manually.

npx

I mentioned earlier that NPM Install is basically used only when new dependencies are introduced, not globally installed. NPM install is also required for global installation. However, NPM install –global should be used with caution to ensure consistency in your development environment. I recommend using global installation only when installing some tools for daily use, while tools needed for project development should be installed as development dependencies and then invoked using NPX.

Is not recommended:

npm install --global webpack
webpack ...
Copy the code

Recommendation:

npm i -D webpack
npx webpack ...
Copy the code

Here i-d is short for install –save-dev.

For one-off, temporary tasks, you can run the tool directly from NPX without having to install it manually and without polluting devDependencies.

For example, if your project was packaged using WebPack and you want to temporarily test the effect of a rollup package:

npx rollup ...
Copy the code

NPX is smart. If rollup is not found in the path, it will be installed automatically.

NPX is great for testing compatibility between versions. Here are some examples.

A cowsay feature or fix that needs to be used has been incorporated into GitHub’s main thread, but has not yet been released on NPMJS. Try it:

npx github:piuccio/cowsay
Copy the code

Temporarily test a branch of Cowsay for internal maintenance:

npx git+ssh://my.hosted.git:cowsay.git#semver:^1
Copy the code

The LTS version of Node (10) is currently in use, and we want to check whether the node 12 build script works:

npx -p node@12 npm run build
Copy the code

As you can see above, when the package name and command name are different (the NPM command is provided by Node), you can specify the package name with the -p option.

npm run

Add commands to the scripts property of package.json (for example: “foo”: “echo foo”) to run the commands from NPM run foo. This is a convenient mechanism provided by NPM to run project-related automation tasks, somewhat like make. However, running make directly (with no arguments) will run the default tasks, but running NPM run directly (with no arguments) will list all the commands declared in scripts.

; npm run
Lifecycle scripts included in leancloud-realtime:
  test
    npm run lint && npm run build && npm run docs && npm run test:node && npm run test:browser

available via `npm run-script`:
  precommit
    pretty-quick --staged
  commitmsg
    commitlint -e $GIT_PARAMS
  lint
    eslint --ignore-path .gitignore src test plugins && tsc realtime.d.ts --strict
  ...
Copy the code

other

Here are a few other tips that I personally don’t find particularly useful, but as everyone’s needs and preferences vary, you might find them useful. If you have any tips you’d like to share, leave a comment.

  • npm init -yBy default,npm initIt’ll let you answer some questions.npm init -yYou can skip these issues and go straight to hands-on development. I don’t recommend it because, in most cases, if you want to get started and develop an application as quickly as possible, you will use frameworks, and almost all frameworks have at least one on NPMJScreate-xxx-appThe package. So basically you don’t get a chance to type innpm initTo answer those questions. And if you’re going to write a component or library, thenpackage.jsonMeta-information is important to the user of the component or library (even if the component or library is only for your own use, future generations may not remember the context in which the component or library was written), and it is not a good idea to skip these issues. Of course, impatience is one of the three great virtues of a programmer, and you might think THAT I can fix it after I finish developing. But, in general, the beginning of the project is when you are most interested (or slightly less averse) to recording this context. If you’re impatient to do it at the beginning of the project, you’ll probably be even less interested once you’re done. Similarly, a README should be written before the project begins.
  • npm repoYou can open your project’s source repository (GitHub in most cases), which has a sister command,npm homeTo open the project’s home page. However, I personally find that an IDE or editor’s intelligent prompts (quick view of types, quick view of documents, quick view of definitions, etc.) are generally more efficient than these two commands.
  • .npmignoreFiles can list files that you don’t want to package and avoid publishing irrelevant files to NPMJS. However, uniform use.gitignoreIt can meet the requirements of most scenarios. Moreover, only exists.gitignoreIn the case of,npm publishWill respect.gitignoreThe statement, while.npmignore 和 .gitignoreIn the case of simultaneous existence,npm publishignore.gitignoreInstead of taking the union of the two. In other words,.gitignoreIgnoring the.npmignoreFiles that are not ignored in the. So, using.npmginoreThis means carefully maintaining two largely duplicate lists at the same time. At the same time, if any one member of the team is accidentally negligent or unfamiliar.npmignore 和 .gitignoreIf the details of the relationship go awry, it is possible to publish sensitive information to NPMJS, resulting in a security breach.
  • Quick versions of various NPM commands, such as the one used abovenpm i -D. These individuals don’t feel the need to remember specifically. Frequently entered commands can benpm helpLet’s see if there’s a short version. It doesn’t matter if you don’t,npm t 和 npm testAnd evennpm run testThe difference is by no means the bottleneck of development efficiency. A lot of times it’s just a matter of personal preference, like people who want to type as little as possiblenpm tPeople who want to remember as little as possible will like itnpm run testNever for the wrong reasonnpm buildsaidnpm run buildOther people might like itnpm testThat’s the middle of the road.
  • npm xmasGuess what you get when you type this command? You can try it yourself. Hint: This command has no utility at all. ; -)