【前端开发】NPM从入门到精通秘籍

NPM，全称 Node Package Manager，是 Node.js 的包管理器，就像是一个超级大管家，专门负责管理 Node.js 项目里的各种第三方模块。打个比方，如果把你的 Node.js 项目比作是一个正在建造的房子，那么 NPM 就是那个神通广大的建材采购助手。你想要添加新功能，比如安装一个处理日期的模块，就像你要给房子添一扇窗户，只要告诉 NPM 你的需求，它就能快速从庞大的 “建材市场”（也就是 NPM 仓库）里找到合适的 “建材”（模块），并帮你安装到项目里。不仅如此，NPM 还能管理这些 “建材” 的版本，确保你的房子在建造和后续维护过程中，使用的都是合适且稳定的 “建材”，让你的项目建造更加轻松、高效。在 Node.js 开发的世界里，NPM 可是起着举足轻重的作用，是开发者们不可或缺的得力助手。

二、为什么要学习 NPM？

在 Node.js 开发的广阔天地里，NPM 可是有着不可替代的重要地位，学习它，好处多多。

（一）高效依赖管理，一键搞定

在实际项目开发中，一个稍微复杂点的项目，往往会依赖众多第三方模块。以一个基于 Node.js 的 Web 应用开发为例，可能会用到 Express 框架来搭建服务器，使用 Mongoose 操作数据库，利用 Axios 进行网络请求等等。如果没有 NPM 帮忙，你就得手动去各个模块的官网下载代码，然后手动配置到项目中，这不仅耗时费力，还容易出错。而有了 NPM，只需在项目根目录下的package.json文件里简单声明这些依赖，然后执行一条npm install命令，NPM 就能自动从 NPM 仓库把所有依赖的模块下载并安装到项目的node_modules目录下，轻松又快捷。

（二）精准版本控制，稳定护航

不同版本的模块可能在功能和 API 上有所差异，要是版本管理不当，很容易引发兼容性问题。NPM 在这方面就做得很好，它支持语义化版本控制。比如，在package.json里指定依赖的版本号，像"express": "^4.17.1" ，这个^符号表示允许安装的版本范围是大于等于 4.17.1，但小于 5.0.0。这样既能保证使用到模块的最新功能，又能避免因版本变动过大导致的不兼容。同时，NPM 还会生成package-lock.json文件，精确记录每个依赖模块的具体版本和依赖关系，确保团队成员在不同环境下安装的依赖版本完全一致，为项目的稳定运行保驾护航。

（三）灵活脚本运行，开发加速

开发过程中，像代码打包、测试、部署等重复性任务，如果每次都手动输入复杂的命令，那效率可太低了。NPM 的脚本功能就能很好地解决这个问题。你可以在package.json的scripts字段中定义各种自定义脚本。比如，定义一个"build": "webpack --config webpack.config.js"脚本，之后只需在命令行中输入npm run build，就能一键执行打包操作。还能通过npm run命令配合不同的脚本，轻松实现测试、启动项目等功能，大大提高开发效率。

三、NPM 基础使用

（一）安装 Node.js 与 NPM

NPM 是 Node.js 的默认包管理器，所以安装 NPM 的前提是先安装 Node.js 。安装步骤如下：

访问 Node.js 官方网站下载页面（https://nodejs.org/e n/dow nload / ），根据你的操作系统选择合适的安装包，比如 Windows 系统下载.msi后缀的安装包，macOS 系统下载.pkg后缀的安装包。

下载完成后，运行安装程序，按照安装向导的提示一步步完成安装，安装过程中可以选择自定义安装路径等设置。

安装完成后，需要验证 Node.js 和 NPM 是否安装成功。打开命令行工具（Windows 下是命令提示符或 PowerShell，macOS 和 Linux 下是终端），分别输入以下命令：

node -v

npm -v

如果成功显示 Node.js 和 NPM 的版本号，就说明安装成功了。比如显示v18.16.0和9.5.1 ，这表明 Node.js 版本是 18.16.0，NPM 版本是 9.5.1 ，你的开发环境已经准备就绪，可以开启 NPM 的探索之旅啦。

（二）初始化项目

当你新建一个 Node.js 项目时，首先要做的就是初始化项目，这时候就需要用到npm init命令。在项目根目录下，打开命令行工具，输入：

npm init

执行这个命令后，它会引导你一步步填写项目的相关信息，比如：

name：项目名称，默认是当前所在文件夹的名称，你也可以根据项目实际情况修改。

version：项目版本号，遵循语义化版本控制规范，默认是1.0.0 。

description：项目描述，简要介绍项目的功能和用途。

entry point：项目入口文件，默认是index.js ，如果你项目的入口文件有其他命名，可以在这里指定。

test command：测试命令，用于指定运行项目测试的命令，比如jest或者mocha ，如果暂时没有测试相关的内容，直接回车跳过就行。

git repository：项目的 Git 仓库地址，如果你打算将项目托管到 GitHub 等代码托管平台，可以在这里填写仓库地址。

author：项目作者信息。

license：项目许可证，默认是ISC ，你可以根据项目的开源协议选择合适的许可证。

如果你不想一步步手动输入这些信息，也可以使用npm init -y命令，这个-y参数表示 “yes”，它会自动采用所有默认值快速生成package.json文件，非常方便快捷。

package.json文件是项目的核心配置文件，它包含了项目的各种元数据和配置信息。下面来详细了解一下其中一些重要字段的含义：

name：项目的名称，在 NPM 仓库中必须是唯一的，不能以.和_开头，也不能包含大写字母，它主要用于标识你的项目，当别人安装你的项目时，就会通过这个名称来查找。

version：项目的版本号，格式为主版本号.次版本号.修订号，比如1.2.3 。主版本号的变动通常意味着有不兼容的 API 更改；次版本号的变动表示增加了新功能且保持向下兼容；修订号的变动一般是修复了一些小的问题或进行了一些小的改进。

description：项目的描述信息，这有助于别人快速了解你的项目是做什么的，在 NPM 仓库页面和搜索结果中会展示这个描述，所以尽量写得简洁明了又能突出项目特点。

main：指定项目的主入口文件，当其他模块通过require引入你的项目时，默认会加载这个文件。比如"main": "app.js" ，就表示项目的入口是app.js文件。

scripts：这是一个非常实用的字段，它定义了一系列可以通过npm run命令执行的脚本。比如"scripts": {"start": "node app.js"} ，这样在命令行中输入npm run start就相当于执行node app.js命令，可以用于启动项目、打包、测试等各种操作，通过自定义脚本，能大大提高开发效率。

dependencies：记录项目运行时所依赖的第三方模块及其版本号。当你执行npm install命令安装模块时，如果没有添加--save-dev参数，模块就会被添加到这个字段中。比如"dependencies": {"express": "^4.17.1"} ，表示项目运行依赖express模块，版本要求是大于等于 4.17.1 且小于 5.0.0 。

devDependencies：记录项目开发过程中所依赖的模块，这些模块通常用于开发、测试、打包等环节，不会在生产环境中使用。像webpack、babel、eslint等工具一般会被添加到这个字段。例如"devDependencies": {"webpack": "^5.75.0", "babel - core": "^6.26.3"} 。

四、NPM 核心操作

（一）安装依赖

在 Node.js 项目开发过程中，安装依赖是 NPM 最常用的功能之一，它能帮助我们快速引入项目所需的各种第三方模块。根据依赖用途的不同，可分为生产依赖和开发依赖，安装方式也略有差异。

1. 生产依赖

生产依赖是项目运行时必不可少的包，像用于构建 Web 服务器的 Express 框架，处理 HTTP 请求的 Axios 库，以及操作数据库的 Mongoose 模块等，都属于生产依赖。安装生产依赖的命令很简单，使用npm install（也可简写为npm i）加上包名即可。例如，要在项目中使用 Express 框架，在项目根目录下的命令行中输入：

npm install express

或者

npm i express

执行这个命令后，NPM 会从 NPM 仓库下载express包及其所有依赖项，并将它们安装到项目的node_modules目录下。同时，package.json文件中的dependencies字段会新增express及其版本号的记录，比如"dependencies": {"express": "^4.18.2"} ，这里的版本号^4.18.2表示允许安装的版本范围是大于等于 4.18.2 且小于 5.0.0 。并且，package-lock.json文件也会被更新，精确记录express包的具体版本、下载来源以及依赖树结构等信息，确保在不同环境下安装的依赖版本完全一致。

2. 开发依赖

开发依赖主要是在项目开发阶段使用的工具包，像代码检查工具 ESLint、测试框架 Jest、打包工具 Webpack 等。这些工具在项目运行时并不是必需的，但在开发过程中却起着至关重要的作用，能帮助我们提高代码质量、进行单元测试以及打包优化项目代码等。安装开发依赖需要使用--save-dev参数（也可简写为-D）。例如，要安装 ESLint 作为项目的开发依赖，在命令行中输入：

npm install eslint --save-dev

或者

npm i eslint -D

安装完成后，package.json文件的devDependencies字段会添加eslint及其版本号，如"devDependencies": {"eslint": "^8.56.0"} ，表明eslint是项目开发过程中的依赖，而非生产环境的依赖。

3. 指定版本安装

默认情况下，npm install命令会安装包的最新版本。但在实际项目中，出于兼容性或稳定性等因素的考虑，我们可能需要安装指定版本的包。这时，只需在包名后面加上@符号和具体的版本号即可。比如，要安装lodash包的 4.17.21 版本，命令如下：

npm install lodash@4.17.21

在指定版本号时，了解语义化版本（SemVer）规范非常重要。语义化版本的格式为主版本号.次版本号.修订号，例如1.2.3 。主版本号的变动通常意味着有不兼容的 API 更改，可能会影响项目的正常运行；次版本号的变动表示增加了新功能且保持向下兼容，一般不会对现有代码造成破坏；修订号的变动一般是修复了一些小的问题或进行了一些小的改进。在package.json文件中，我们可以使用一些符号来灵活指定版本范围，除了前面提到的^符号，还有~符号，~表示允许安装的版本范围是保持次版本号不变，修订号可以更新。例如，"lodash": "~4.17.21" ，表示可以安装 4.17.x 系列中最新的修订版本。合理运用语义化版本，能更好地控制项目依赖的版本，确保项目的稳定性和兼容性。

（二）卸载依赖

当项目中不再需要某个依赖包时，可以使用npm uninstall命令（也可简写为npm un）将其卸载。卸载命令的基本语法是npm uninstall <package-name> ，例如要卸载项目中的express包，在项目根目录的命令行中输入：

npm uninstall express

或者

npm un express

执行卸载命令后，NPM 会从项目的node_modules目录中删除express包及其相关的依赖文件。同时，package.json文件中的dependencies字段（如果是开发依赖，则是devDependencies字段）也会移除express的记录。如果项目中存在package-lock.json文件，它也会相应地更新，移除与express包相关的版本和依赖信息，确保项目的依赖管理文件与实际安装的依赖保持一致。

（三）批量安装依赖

在实际开发中，当我们接手一个已有的项目或者将项目分享给他人时，需要安装项目所需的所有依赖。这时，利用package.json文件就可以轻松实现批量安装依赖。在项目根目录下，打开命令行工具，输入：

npm install

这条命令会读取package.json文件中的dependencies和devDependencies字段，然后从 NPM 仓库下载并安装这些字段中列出的所有依赖包及其对应的版本，将它们安装到node_modules目录下。这样，就可以快速搭建起与项目开发者相同的开发环境，避免因依赖不一致而导致的各种问题。

五、NPM 脚本：自动化开发流程

（一）定义脚本

在package.json文件中，有一个非常实用的scripts字段，通过它可以定义各种自定义脚本，将一些常用的命令组合或简化，方便在开发过程中快速执行。定义脚本的语法很简单，在scripts字段中添加一个键值对，键就是脚本的名称，值则是对应的命令。比如，在一个基于 Node.js 的 Web 项目中，要启动一个开发服务器，可以这样定义：

{

"scripts": {

"start": "node server.js"

}

这里定义了一个名为start的脚本，其对应的命令是node server.js ，表示启动server.js文件，运行项目的服务器。再比如，使用 Webpack 进行项目打包，假设 Webpack 的配置文件是webpack.config.js ，可以定义如下脚本：

{

"scripts": {

"build": "webpack --config webpack.config.js"

}

这样，build脚本就代表了使用指定配置文件进行 Webpack 打包的操作。除了这些简单的示例，还可以定义更复杂的脚本。例如，在一个使用 ESLint 进行代码检查，同时使用 Jest 进行单元测试的项目中，可以这样定义脚本：

{

"scripts": {

"lint": "eslint src",

"test": "jest",

"predeploy": "npm run lint && npm run test",

"deploy": "echo 'Deploying...'"

}

这里定义了lint脚本用于检查src目录下的代码是否符合 ESLint 规则；test脚本用于运行 Jest 测试；predeploy脚本先执行代码检查和测试，只有这两个步骤都通过后，才会执行deploy脚本，deploy脚本目前只是简单地输出 “Deploying...”，实际应用中可以替换为真正的部署命令。通过合理定义这些脚本，可以将项目开发过程中的各种操作规范化、自动化，提高开发效率。

（二）运行脚本

定义好 NPM 脚本后，运行脚本也非常简单，只需在命令行中使用npm run加上脚本名称即可。比如，运行前面定义的start脚本，在项目根目录下的命令行中输入：

npm run start

如果脚本名称比较简短，也可以使用简写形式npm start ，效果是一样的。当执行npm run start命令时，命令行就会执行package.json中scripts.start字段对应的node server.js命令，启动项目的服务器。运行build脚本的命令是：

npm run build

执行该命令后，就会按照webpack.config.js的配置进行项目打包操作。如果在运行脚本时需要传递一些参数给脚本对应的命令，可以在脚本名称后面加上-- ，然后跟上参数。例如，在运行test脚本时，想要指定测试文件的路径，可以这样输入：

npm run test -- --coverage --testPathPattern=src/utils

这里--coverage和--testPathPattern=src/utils就是传递给jest命令的参数，--coverage表示生成测试覆盖率报告，--testPathPattern=src/utils表示只测试src/utils目录下的文件。通过这种方式，可以灵活地控制脚本的执行行为，满足不同的开发需求。

（三）脚本进阶：生命周期钩子

NPM 脚本提供了强大的生命周期钩子功能，它允许我们在脚本执行的不同阶段自动执行一些额外的操作，使得项目的自动化流程更加完善。生命周期钩子的命名遵循一定的规则，对于在scripts字段中定义的任何脚本命令，都可以通过添加pre或post前缀来定义该命令执行前后的钩子脚本。比如，有一个名为build的脚本，就可以定义prebuild和postbuild钩子。prebuild钩子会在build脚本执行之前运行，postbuild钩子会在build脚本执行之后运行。

以一个实际的项目场景为例，假设在使用 Webpack 打包项目时，希望在打包前先清理一下之前生成的打包文件，打包后再自动打开打包后的页面。可以这样配置package.json中的脚本：

{

"scripts": {

"prebuild": "rm -rf dist && mkdir dist",

"build": "webpack --config webpack.config.js",

"postbuild": "open dist/index.html"

}

当执行npm run build命令时，会先执行prebuild钩子对应的命令rm -rf dist && mkdir dist ，这条命令会删除dist目录（如果存在的话），然后重新创建一个空的dist目录，用于存放新的打包文件。接着执行build脚本，按照 Webpack 的配置进行项目打包。打包完成后，会自动执行postbuild钩子对应的命令open dist/index.html ，在默认浏览器中打开打包后的index.html页面，方便查看打包后的效果。

除了pre和post钩子，还有一些特殊的全局生命周期钩子，比如install钩子。install钩子会在npm install命令执行时触发。如果在项目中需要在安装依赖后自动执行一些初始化操作，就可以利用这个钩子。例如，有些项目可能需要在安装依赖后生成一些配置文件，或者安装一些额外的系统级依赖。可以在package.json中这样配置：

{

"scripts": {

"install": "node scripts/init.js"

}

这样，当执行npm install命令安装项目依赖时，安装完成后就会自动执行node scripts/init.js命令，运行init.js脚本进行相关的初始化操作。通过合理运用这些生命周期钩子，可以将项目开发过程中的各种操作紧密地串联起来，实现更加高效、自动化的开发流程。

（四）常用场景

NPM 脚本在项目开发的各个环节都有着广泛的应用，以下是一些常见的使用场景。

1. 启动项目

在开发基于 Node.js 的 Web 应用时，通常需要启动一个服务器来运行项目。通过 NPM 脚本，可以轻松实现这一操作。比如，在一个使用 Express 框架搭建的 Web 项目中，package.json中的脚本配置如下：

{

"scripts": {

"start": "node app.js"

}

其中app.js是项目的入口文件，负责启动 Express 服务器。在项目根目录下执行npm start命令，就可以快速启动项目，开始进行开发和调试。

2. 构建项目

构建项目是将源代码转换为可部署的生产代码的过程，这通常涉及到代码打包、压缩、编译等操作。以使用 Webpack 进行前端项目构建为例，在package.json中可以这样配置脚本：

{

"scripts": {

"build": "webpack --config webpack.config.js"

}

执行npm run build命令后，Webpack 会根据webpack.config.js中的配置，对项目中的 JavaScript、CSS、HTML 等文件进行打包处理，将多个文件合并成一个或几个文件，并进行压缩优化，生成适合在生产环境中部署的代码。

3. 测试项目

单元测试是保证代码质量的重要手段，NPM 脚本可以方便地运行各种测试框架。例如，在一个使用 Jest 进行单元测试的项目中，package.json的脚本配置如下：

{

"scripts": {

"test": "jest"

}

执行npm test命令，Jest 会自动查找项目中的测试文件（通常以.test.js或.spec.js结尾），并运行这些测试用例，检查代码的功能是否符合预期。如果项目还使用了 ESLint 进行代码质量检查，也可以通过 NPM 脚本将测试和代码检查结合起来，例如：

{

"scripts": {

"lint": "eslint src",

"test": "jest",

"test:all": "npm run lint && npm run test"

}

执行npm run test:all命令，会先执行eslint src进行代码检查，检查通过后再执行jest运行测试用例，确保代码既符合规范又功能正确。

六、NPM 进阶技巧

（一）语义化版本符号详解

在 NPM 的世界里，语义化版本是确保项目依赖稳定性和兼容性的关键。语义化版本的格式为主版本号.次版本号.修订号，比如2.3.4 ，每个部分都有着明确的含义：

主版本号：当进行了不兼容的 API 更改，或者对项目进行了重大的、可能影响现有功能的修改时，主版本号会递增。例如，从 Express 4.x 升级到 Express 5.x ，可能会涉及到路由、中间件等核心功能的变化，这种情况下就需要谨慎评估对项目的影响，因为高版本的 API 可能与现有代码不兼容，需要对代码进行相应的调整。

次版本号：在保持向下兼容的前提下，增加了新功能时，次版本号会递增。以 Vue.js 为例，从 Vue 2.5 升级到 Vue 2.6 ，新增了一些语法糖和功能优化，老代码依然可以正常运行，并且还能享受到新功能带来的便利，项目可以相对轻松地进行版本升级。

修订号：主要用于修复一些小的问题，比如修复了某个已知的 Bug ，或者进行了一些不影响功能的小改进，修订号就会递增。从 Webpack 5.74.0 升级到 5.75.0 ，可能只是修复了某个文件加载的小问题，对于大多数项目来说，直接升级修订版本通常是比较安全的。

在package.json文件中，我们常常会看到版本号前面带有一些符号，这些符号进一步定义了依赖版本的允许更新范围：

^（插入符号）：允许升级到最新的次版本号和修订号，但要保持主版本号不变。例如，"lodash": "^4.17.21" ，这意味着 NPM 在安装依赖时，会安装大于等于 4.17.21 且小于 5.0.0 的版本，也就是可以安装 4.17.22、4.18.0 等版本。这种方式适用于希望在不破坏主版本兼容性的前提下，自动获取向下兼容的新功能和补丁更新，在开发环境中较为常用，能及时享受到新功能带来的好处。

~（波浪线）：只允许升级到最新的修订号版本，主版本号和次版本号保持不变。比如"axios": "~0.27.2" ，表示可以安装 0.27.3、0.27.4 等修订版本，但不会安装 0.28.0 及以上的版本。这种方式更注重稳定性，适用于对稳定性要求较高的生产环境，只接受修复 Bug 的补丁更新，降低引入不兼容更改的风险。

（二）使用.npmrc 配置 npm

.npmrc是 NPM 的配置文件，它就像是 NPM 的 “个性化设置中心”，可以帮助我们自定义 NPM 的行为，让 NPM 更好地适应不同的开发环境和需求。这个文件通常位于用户主目录下（比如在 Windows 系统中，路径可能是C:\Users\你的用户名\.npmrc ；在 macOS 和 Linux 系统中，路径是~/.npmrc ），也可以存在于项目根目录下，项目根目录下的.npmrc文件优先级更高，会覆盖用户主目录下的配置。

.npmrc文件的主要作用之一是配置自定义镜像源。在国内，由于网络限制，直接使用 NPM 的官方源下载依赖包，速度可能会比较慢，甚至会出现下载失败的情况。这时候，我们可以通过配置镜像源来解决这个问题。例如，使用淘宝镜像源，只需要在.npmrc文件中添加一行配置：

registry=https://registry.npm.taobao.org

这样，当执行npm install命令

七、NPM 发布包

八、常见问题及解决方法

在使用 NPM 的过程中，开发者可能会遇到各种问题，下面为大家介绍一些常见问题及对应的解决方法。

（一）权限问题

在使用 NPM 全局安装包时，尤其是在 Unix 或 Linux 系统上，可能会遇到权限不足的问题，导致安装失败，错误信息通常类似于 “Error: EACCES: permission denied” 。这是因为 NPM 默认的全局安装目录需要管理员权限才能写入，而普通用户没有足够的权限。

解决方法如下：

使用 sudo 命令：在命令前加上sudo来提升权限，以安装全局包为例，命令如下：

sudo npm install -g <package - name>

但频繁使用sudo可能会带来安全风险，因为它赋予了超级用户权限。

更改 NPM 全局安装目录：创建一个新的目录，用于存放全局安装的包，然后配置 NPM 使用这个新目录。比如在用户主目录下创建.npm - global目录：

mkdir ~/.npm - global

npm config set prefix '~/.npm - global'

接着，需要在 Shell 配置文件（如~/.bashrc或~/.zshrc）中添加以下行，将新目录添加到系统路径中：

export PATH=~/.npm - global/bin:$PATH

添加完成后，重新加载 Shell 配置文件，使设置生效：

source ~/.bashrc

这样，以后再全局安装包时，就不会因为权限问题而报错了。

（二）版本冲突

当一个项目中有多个包依赖于不同版本的同一个包，或者不同包之间的依赖版本不兼容时，就会出现版本冲突问题。比如，项目中 A 包依赖lodash的 4.17.20 版本，B 包依赖lodash的 4.17.25 版本，这就可能导致版本冲突。在执行npm install命令时，控制台可能会输出类似 “UNMET PEER DEPENDENCY” 的错误信息，提示存在依赖冲突。

解决方法如下：