说实话，workspace 这个功能我一开始是拒绝的。作为一个"老派"开发者，我觉得 npm link 就够用了，为什么要搞个 workspace 出来？直到去年接手一个大型项目，被十几个相互依赖的包折磨得焦头烂额时，我才真正体会到 workspace 的威力。
那些年被多包管理折磨的日子
还记得当时的情况：一个项目拆分成十几个包，有核心工具库、组件库、业务模块、工具函数等等。每次改一个 bug，我都要：
- 修改工具库代码
- npm run build 打包
- npm pack 打成 tar.gz 包
- 切到主项目目录
- npm install ../tool-lib/tool-lib-1.0.0.tgz
- 测试通过后再发布到 npm
- 主项目再安装正式版本
一套流程下来，一天时间就没了。更痛苦的是，如果测试发现问题，整个流程还得再来一遍。
workspace 到底是什么神仙功能？
简单来说，workspace 就是 npm 7+ 提供的多包管理解决方案。它让你可以在一个根目录下管理多个相互关联的 npm 包，而且这些包之间可以像安装了正式版本一样直接引用。
听起来很抽象？让我用一个实际的例子来说明。
实战演示：创建一个 workspace 项目
假设我们要开发一个电商系统，包含以下几个包：
@myshop/core：核心业务逻辑@myshop/components：UI 组件库@myshop/utils：工具函数库@myshop/web：主网站应用
第一步：创建项目结构
myshop-project/
├── package.json
├── packages/
│ ├── core/
│ │ └── package.json
│ ├── components/
│ │ └── package.json
│ ├── utils/
│ │ └── package.json
│ └── web/
│ └── package.json
第二步：配置根目录的 package.json
{
"name": "myshop-project",
"private": true,
"workspaces": [
"packages/*"
]
}
注意两个关键点：
"private": true- 根项目必须是私有的"workspaces": ["packages/*"]- 告诉 npm 哪些目录是工作区
第三步：各个包的配置
packages/utils/package.json:
{
"name": "@myshop/utils",
"version": "1.0.0",
"main": "index.js"
}
packages/components/package.json:
{
"name": "@myshop/components",
"version": "1.0.0",
"main": "index.js",
"dependencies": {
"@myshop/utils": "^1.0.0"
}
}
注意这里！components 包直接引用了 utils 包，就像引用一个正常的 npm 包一样。
workspace 的神奇之处在哪？
1. 自动链接，实时生效
在根目录运行 npm install 后，npm 会自动处理包之间的依赖关系。当你修改 @myshop/utils 的代码时，@myshop/components 中引用的代码会立即生效，不需要重新安装！
2. 统一管理依赖
你可以在根目录统一安装所有包都需要的依赖：
# 在根目录安装
npm install lodash --workspaces
# 这会为所有工作区都安装 lodash
也可以为特定包安装依赖：
# 只为 web 包安装 react
npm install react --workspace=@myshop/web
3. 一键执行脚本
想要同时为所有包执行构建命令？
npm run build --workspaces
想要为特定包执行测试？
npm test --workspace=@myshop/components
实际项目中的最佳实践
1. 合理的目录结构
monorepo-project/
├── package.json # 根配置文件
├── packages/ # 所有包的目录
│ ├── shared/ # 共享代码
│ │ ├── types/ # TypeScript 类型定义
│ │ └── constants/ # 常量定义
│ ├── components/ # 组件库
│ ├── services/ # 服务层
│ ├── web/ # Web 应用
│ └── mobile/ # 移动端应用
└── apps/ # 应用入口
├── admin/ # 管理后台
└── client/ # 用户端
2. 智能的依赖管理策略
// 根目录 package.json
{
"name": "my-project",
"private": true,
"workspaces": [
"packages/*",
"apps/*"
],
"devDependencies": {
"typescript": "^5.0.0",
"eslint": "^8.0.0",
"jest": "^29.0.0"
}
}
将所有包共用的开发工具安装在根目录，减少重复安装。
3. 版本管理技巧
对于相互依赖的包，建议使用相对版本号：
{
"dependencies": {
"@myshop/utils": "^1.0.0",
"@myshop/components": "workspace:^1.0.0"
}
}
workspace:^1.0.0 告诉 npm 优先使用工作区内的版本。
常见问题和解决方案
问题1：包之间的依赖找不到
确保：
- 根目录 package.json 配置了正确的 workspaces
- 被依赖的包 name 和版本号正确
- 运行了
npm install
问题2：修改代码后没有生效
检查：
- 是否在根目录运行了
npm install - 被修改的包是否正确导出了变更
- 引用方是否正确重新构建
问题3：发布包时出现问题
发布工作区包时，需要在对应的包目录下运行：
cd packages/utils
npm publish
workspace vs 其他方案对比
| 方案 | 优点 | 缺点 |
|---|---|---|
| workspace | 原生支持、简单易用、自动链接 | 功能相对基础 |
| Lerna | 功能强大、版本管理完善 | 配置复杂、学习成本高 |
| npm link | 灵活、可控 | 手动管理麻烦、容易出错 |
对于大多数项目，workspace 已经足够用了。
写在最后
workspace 看似只是一个简单的多包管理工具，但它背后体现的是现代前端开发对复杂项目管理的需求。掌握好 workspace，不仅能提升开发效率，更能让你在团队协作中游刃有余。
下次当你面对多个相互关联的包时，不妨试试 workspace。相信我，一旦用上了，你就再也回不去了！
如果你正在维护一个多包项目，或者准备拆分项目结构，强烈建议试试 workspace。这可能是你提升开发效率的最简单方式之一。
