第2章 Node.js与包管理器
12 分钟阅读
Chapter-02 - Node.js 与包管理器
2.1 Node.js 简介
你有没有想过这样一个问题:JavaScript 这门语言,不是只能在浏览器里运行吗?它是怎么跑到服务器上去的?Node.js 就是这个"魔法"的化身——它把 Chrome 浏览器的 V8 引擎单独拎出来,放到一个没有浏览器的环境里运行,于是 JavaScript 第一次能够在服务器端大展拳脚。
2.1.1 Node.js 的安装:LTS 与 Current 版本的选择
Node.js 的安装有两种版本路线,像两条不同的登山道——一条稳定但风景一般,一条时髦但可能有坑。
- LTS 版本(Long Term Support,长期支持版):适合绝大多数人,稳定、可靠、社区支持好,企业用这个。版本号比如
20.x.x、22.x.x - Current 版本(当前最新版):最新功能都在这儿,但可能有些不稳定,适合爱折腾的极客。版本号通常是
21.x.x、23.x.x
对于 React 开发来说,直接选 LTS 版本,稳如老狗,不翻车。
安装方法(Windows / macOS / Linux 全覆盖):
方法一:官网下载安装包(适合 Windows 用户)
去 nodejs.org,你会看到两个大按钮:
- LTS(推荐大多数用户使用)✅
- Current(最新功能,但可能不稳定)
点 LTS,下载 .msi 安装包,一路下一步-next-下一步-next,就装好了。
方法二:命令行安装(适合所有平台,推荐开发者使用)
| |
2.1.2 nvm(Node Version Manager):多版本管理
nvm 是什么?它是 Node.js 的"时光机"和"分身术"——让你在同一台电脑上同时安装和切换多个 Node.js 版本。
场景模拟:你同时在维护两个项目:项目 A 用 Node 16,项目 B 用 Node 22。没有 nvm?你得每次手动卸载重装,烦死。有了 nvm?一个命令切换版本,丝滑流畅。
安装 nvm(以 macOS/Linux 为例,Windows 用户用 nvm-windows):
| |
nvm 常用命令:
| |
💡 小技巧:Windows 用户请搜索
nvm-windows下载安装,功能和 macOS 版的 nvm 类似。安装的时候记得用管理员身份运行安装程序,不然可能会遇到权限问题。
2.1.3 验证安装:node -v / npm -v
安装完 Node.js 之后,我们来验证一下是否安装成功!
打开你的终端(Terminal):
- Windows:按
Win + X,选择"终端"或"PowerShell" - macOS:按
Command + Space,搜索"终端" - Linux:按
Ctrl + Alt + T
然后分别运行以下两条命令:
| |
如果两条命令都输出了版本号(比如 v20.14.0 和 10.8.2),恭喜你!Node.js 安装成功!🎉
常见坑:如果提示"node 不是内部或外部命令",说明安装没成功或者环境变量没配置好。解决方法:重启终端/电脑,或者手动把 Node.js 的路径加到系统 PATH 里。
2.2 npm 详解
npm 是 Node Package Manager 的缩写,中文名叫"节点包管理器"。你可以把它理解为 JavaScript 世界的"应用商店"——它托管了全世界开发者写的各种工具库,你只需要一个命令,就能把这些库下载到自己的项目里。
搞笑比喻:没有 npm 之前,JavaScript 开发者就像要去图书馆借书,得先自己去找、自己搬回来。有了 npm,就像有了外卖软件——你想吃什么,点一下,就给你送到家门口,还帮你拆好包装!
2.2.1 npm init:初始化项目
当你开始一个新项目时,第一步就是用 npm init 来"初始化"这个项目——相当于给它办一张身份证,告诉 npm:“这个文件夹是我的地盘了。”
| |
运行之后,你会在当前文件夹里发现一个 package.json 文件,它长这样:
| |
📝 补充:如果你用
npm init -y,所有的选项都用默认值填充。后续你可以随时手动修改package.json文件,或者用npm config set命令来修改某个字段。
2.2.2 npm install / –save / –save-dev:安装依赖
这是 npm 最最最常用的命令!安装一个第三方包,就像在手机上点外卖一样简单。
| |
dependencies vs devDependencies 有什么区别?
用一个生活中的例子来解释:
- dependencies(生产依赖):就像盖房子用的砖头、水泥——房子盖好后,这些东西还留在房子里,是必需品。React、Vue、Axios 等属于这类。
- devDependencies(开发依赖):就像盖房子用的脚手架、安全帽——房子盖好后,这些东西就拆掉了,不需要留在房子里。ESLint、Prettier、Webpack 等属于这类。
| |
2.2.3 npm scripts:package.json scripts 字段
package.json 里的 scripts 字段,是 npm 的"快捷命令"区域。你可以在这里定义一些常用的命令,给它们起简单的名字,之后运行 npm run xxx 就能执行对应的脚本。
| |
定义了之后,运行方式是:
| |
💡 小技巧:npm 还内置了一些特殊脚本,不需要
run这个前缀,可以直接用npm test、npm start、npm stop。其中start通常用于启动生产服务器,test用于运行测试。
2.2.4 npm install vs npm ci 的区别
这里有两个命令看起来差不多,实际上区别很大:
| |
记住这个原则:开发用
npm install,部署用npm ci!团队协作时,建议把package-lock.json也提交到 Git 仓库,这样大家的依赖版本完全一致,不会有"我本地能用,你本地不行"的尴尬。
2.2.5 package-lock.json 的作用
package-lock.json 是 npm 5.0 之后引入的文件,它的职责是精确锁定依赖树的版本。
你可能会问:package.json 里不是已经写了 "react": "^18.2.0" 吗?为什么还需要 package-lock.json?
好问题!区别在于:
package.json里写的是范围:^18.2.0意味着"安装 18.2.0 到 18.x.x 之间最新的版本"package-lock.json里写的是精确版本:react: 18.2.0,甚至每个依赖的依赖(传递依赖)的精确版本都有记录
| |
这样做的好处是:每次 npm install,不管是谁、在哪台机器上安装,安装出来的依赖树是完全一致的。不再有"在我这里好好的,在你那里就不行"的问题!
2.3 npx:无需全局安装即可运行命令
npx 是 npm 5.2.0 之后自带的工具,它解决了两个问题:
- 不想全局安装某个工具,但又想运行它——
npx来帮你临时运行 - 想运行某个命令但不知道它在哪——
npx会自动在本地找,找不到就去网上下载
2.3.1 npx create-vite / npx create-react-app
我们后面会学到,创建 React 项目最简单的方式就是用 Vite。而 create-vite 这个工具,用 npx 来运行就非常方便:
| |
同理,如果你用 Create React App(Facebook 官方的老牌创建工具):
| |
2.3.2 npx vs 全局安装的优劣对比
| 对比项 | npx(临时运行) | 全局安装 |
|---|---|---|
| 磁盘空间 | 不占全局空间(用完即删) | 一直占用空间 |
| 版本控制 | 每个项目可以用不同版本 | 全局只有一个版本 |
| 污染全局命名空间 | 不会 | 久了全局一堆不知道干啥的包 |
| 适合场景 | 一次性命令、创建项目脚手架 | 长期使用的 CLI 工具(如 eslint、prettier) |
小建议:
- 脚手架工具(create-vite、create-next-app 等)→ 用
npx,用完就走,不占地方- 长期工具(eslint、prettier)→ 全局安装一次,之后随时用
2.4 pnpm 与 yarn:npm 的替代品
npm 虽然是 Node.js 官方的包管理器,但它有几个让人头疼的问题:
- 安装速度慢(有时慢到让人去泡杯咖啡)
- 磁盘占用大(同样的包被安装很多份)
- 依赖树管理有时候很混乱
于是,pnpm 和 yarn 这两位"挑战者"应运而生。
2.4.1 pnpm 的优势:快、省空间
pnpm(Performant npm,高性能 npm)是由 npm 的前员工开发的,它的核心创新是硬链接(Hard Link)和符号链接(Symbolic Link)。
简单说,pnpm 不会把你的依赖复制到每个项目的 node_modules 里,而是共享同一份物理文件。就像图书馆的书,所有人可以在不同楼层、不同房间"借阅"同一本书,而不需要每层楼都买一本。
| |
pnpm 的优势:
- 速度快:因为它使用了并行的下载策略
- 省空间:所有项目共享同一份依赖包,不重复存储
- 更安全:pnpm 用了特殊的目录结构,防止幽灵依赖(Phantom Dependencies)——即项目里明明没装这个包,但 Node 却能找到它的问题
2.4.2 pnpm 的安装与基本使用
| |
2.4.3 workspaces:monorepo 管理
pnpm workspaces(工作区)是 pnpm 的一个超强大功能,它允许你在一个代码仓库里管理多个子项目(也叫 monorepo 单体仓库)。
场景是这样的:你有一个 React 项目,里面有一个组件库、一个工具库、一个文档站点——三个项目有共享的依赖,但又需要分开管理。传统的做法是建三个独立的 Git 仓库,三个 node_modules,三个 package-lock.json……光想想就头疼。
pnpm workspaces 帮你解决这个问题:
| |
目录结构变成这样:
my-monorepo/
├── package.json
├── pnpm-workspace.yaml // pnpm 工作区配置文件
└── packages/
├── components/ // 组件库
│ ├── package.json
│ └── src/
├── utils/ // 工具库
│ ├── package.json
│ └── src/
└── docs/ // 文档站点
├── package.json
└── src/
pnpm-workspace.yaml 的内容非常简单,只需要声明工作区的路径即可:
| |
根目录运行一次 pnpm install,所有子项目的依赖都会被安装,而且共享的依赖只会在磁盘上存一份!
🔥 React 官方(包括 Vite)从 2023 年开始官方支持 pnpm workspace,如果你的团队使用 monorepo 结构,强烈建议试试 pnpm!
本章小结
本章我们搞定了 React 开发的第一组"地基工具":
- Node.js:JavaScript 的运行时环境,让 JS 能够跑在服务器端和本地命令行
- npm:Node.js 官方的包管理器,“JavaScript 世界的应用商店”,用
npm install安装依赖,用npm init初始化项目 - npx:npm 内置的命令运行器,让你无需全局安装就能临时运行各种 CLI 工具
- pnpm / yarn:npm 的强力替代品,pnpm 以"硬链接共享"技术著称,yarn 以稳定和功能丰富著称
下一章,我们将配置开发工具——Visual Studio Code、插件、快捷键……让你的"武器库"武装到牙齿!💻🚀