第一章：依赖管理概述

大家好，我是你们这门课的主讲人。今天咱们聊聊前端工程化里最基础、也最绕不开的一个话题——依赖管理。

说实话，我见过不少刚入行的同学，上来就 npm install，装完就跑。问他装了什么、为什么装、版本怎么锁的，一脸懵。这其实挺危险的。依赖管理看似简单，但坑特别多。我当年刚带团队时，就因为在依赖版本上栽过跟头，导致整个项目回滚了两次。嗯，从那以后，我对这块就特别较真。

什么是依赖管理？

说白了，依赖管理就是帮你管好项目里那些“别人写的代码”。

你写一个按钮组件，可能用了 lodash 的深拷贝，用了 dayjs 处理时间，用了 axios 发请求。这些第三方库，就是你的“依赖”。

依赖管理要干三件事：

• 记录：项目用了哪些包、什么版本
• 安装：把需要的包下载到本地
• 维护：升级、降级、删除、解决冲突

你想想看，如果没有依赖管理，你得手动去 GitHub 下载每个库的压缩包，解压，放到项目里，再手动引入。版本更新了还得重新下载替换。一个项目几十个依赖，光维护就能把人逼疯。

为什么需要依赖管理？

这个问题我问过不少学员。有人回答“因为大家都在用”，有人回答“因为 npm 很方便”。都对，但不够本质。

我个人觉得，依赖管理解决了三个核心痛点：

1. 版本冲突：项目 A 需要 lodash 4.0，项目 B 需要 lodash 3.0。没有依赖管理，你只能手动复制两份，命名成 lodash4 和 lodash3。想想就头疼。
2. 可复现性：你本地跑得好好的，同事一拉代码就报错。为什么？因为依赖版本不一致。依赖管理通过 lock 文件锁死版本，保证“你装的和同事装的一模一样”。
3. 传递依赖：你装了 axios，axios 又依赖了 follow-redirects。没有依赖管理，你得手动把 follow-redirects 也装上。依赖管理会自动处理这种“依赖的依赖”。

前端依赖管理的演进历史

这部分我特别喜欢讲，因为能看清来路，才知道现在用的工具好在哪。

1. 手动下载时代（2010 年以前）

那时候前端项目还比较简单。你要用 jQuery？去官网下载 jquery.min.js，放到项目的 lib 文件夹里。要用 underscore？同样操作。

问题很明显：

• 版本全靠自己记
• 升级要手动替换文件
• 没有依赖树的概念，所有库都是平铺的
• 团队协作时，每个人下载的版本可能不一样

我记得当时有个项目，用了 20 多个 jQuery 插件。每次升级 jQuery 版本，都要手动测试所有插件是否兼容。那叫一个酸爽。

2. Bower 时代（2012-2015）

Bower 是 Twitter 推出的前端包管理器。它比手动下载强多了，至少能通过命令行安装和更新。

bower install jquery#1.11.0
bower update jquery

但 Bower 有个致命问题：它只管理前端库，不处理模块化。你下载了库，还得手动在 HTML 里用 script 标签引入。而且 Bower 的依赖树是扁平的，版本冲突时经常报错。

3. npm 的崛起（2015 至今）

npm 最初是 Node.js 的包管理器，但随着前端工程化的发展，它逐渐成了前端依赖管理的事实标准。

npm 的核心优势：

• 支持嵌套依赖树，每个包可以有自己的 node_modules
• 有 package.json 记录依赖信息
• 有 npm registry 作为中央仓库
• 支持语义化版本（SemVer）

但 npm 早期版本也有问题。比如 node_modules 嵌套太深，Windows 上路径超长会报错。还有著名的“幽灵依赖”——你明明没装某个包，但因为别的包装了它，你也能引用到。

// 早期 npm 的 node_modules 结构
node_modules/
  ├── package-a/
  │   └── node_modules/
  │       └── package-b/
  └── package-c/
      └── node_modules/
          └── package-b/  // 同一个包装了两次

4. yarn 的诞生（2016）

Facebook 受不了 npm 的速度和稳定性问题，自己搞了 yarn。yarn 带来了几个关键改进：

• lock 文件：yarn.lock 锁死所有依赖的精确版本
• 并行安装：比 npm 快好几倍
• 离线缓存：装过的包不用重复下载
• 确定性安装：同一份 lock 文件，在任何机器上装出来的 node_modules 完全一样

说实话，yarn 刚出来那会儿，我立马就把团队的项目全切过去了。那个安装速度的提升，真的是肉眼可见。

5. pnpm 的革新（2017 至今）

pnpm 是我现在最常用的工具。它解决了一个 npm 和 yarn 都没搞定的问题——磁盘空间浪费。

pnpm 的原理很巧妙：

• 所有包都存到一个全局 store 里
• 项目里的 node_modules 只是硬链接或软链接
• 同一个版本的文件，磁盘上只存一份

举个例子，你 10 个项目都用 lodash 4.17.21。npm 会在每个项目里都复制一份，占用 10 份磁盘空间。pnpm 只存一份，其他项目通过链接引用。

# pnpm 的 node_modules 结构（简化）
node_modules/
  .pnpm/
    lodash@4.17.21/node_modules/lodash  // 实际文件
  lodash -> .pnpm/lodash@4.17.21/node_modules/lodash  // 软链接

而且 pnpm 的依赖树是严格的——你只能引用 package.json 里声明过的依赖。这彻底解决了“幽灵依赖”的问题。

小结

依赖管理的发展，说白了就是不断解决前人留下的坑。从手动下载到 pnpm，每一步都在让前端开发更规范、更高效。

下一章，我会带大家深入 package.json 的每一个字段。很多同学只会在里面写 dependencies 和 devDependencies，其实里面藏着不少好东西。咱们下节见。