Yarn 入门：我如何从包管理器理解前端项目的依赖边界

我第一次接触 Yarn 时，把它理解成 npm 的另一个命令。

能安装包，能初始化项目，能管理依赖，好像也就这样。

后来我接触的前端项目越来越多，才发现包管理器已经进入了项目边界。

它决定项目依赖怎么进入、版本怎么锁定、团队环境怎么一致、构建问题怎么复现。

所以我现在看 Yarn，不只是看它有哪些命令，而是看它如何帮我管理一个项目的依赖边界。

我会先理解 package.json

任何 Node 或前端项目，package.json 都是入口。

它记录项目名称、脚本、依赖、开发依赖和一些工具配置。

包管理器真正做的事情，是根据这份描述把项目需要的外部代码安装进来，并尽量让不同机器上的结果一致。

所以学习 Yarn 的第一步，不是背命令，而是理解依赖为什么要被记录下来。

我常用的命令

初始化项目：

安装项目依赖：

或：

添加运行时依赖：

添加开发依赖：

移除依赖：

升级依赖：

这些命令本身并不复杂。

真正重要的是，我要知道每次添加依赖时，它会改变 package.json 和 lockfile。

我会如何区分依赖类型

dependencies 是项目运行时需要的依赖。

比如 Web 服务启动、页面运行、核心业务逻辑需要的包，通常放在这里。

devDependencies 是开发阶段需要的依赖。

比如构建工具、测试框架、格式化工具、类型定义和本地开发辅助工具。

peerDependencies 更常见于库和插件开发，用来说明当前包希望宿主项目提供什么依赖版本。

optionalDependencies 则表示某些包安装失败时，项目仍然可以继续工作。

我现在不会随手把所有东西都加进 dependencies。

依赖放错位置，会影响构建体积、部署环境和后续维护。

我的使用习惯

我会把 lockfile 提交到仓库。

因为它记录了实际安装版本，是团队复现环境的重要依据。

我也会避免在同一个项目里混用 npm、Yarn、pnpm。

包管理器混用时，lockfile 容易互相打架，依赖树也可能变得难以解释。

如果项目已经选定 Yarn，我就让团队统一使用 Yarn。

如果需要迁移到 pnpm 或 npm，也会把这件事当成一次明确迁移，而不是随手换命令。

我的边界

包管理器解决的是依赖安装问题，不负责替我判断依赖是否值得引入。

每加一个包，我都会多问一句：

这个包是否真的必要？

是否还在维护？

是否会引入很大的依赖树？

是否影响构建、部署或安全边界？

能不能用平台原生能力或已有工具解决？

Yarn 入门很简单，但依赖管理这件事并不简单。

当我能解释每一个依赖为什么存在，前端项目才会越来越稳，而不是越来越重。