使用 npm workspace 管理多包的核心做法是在项目根目录的 package.json 中配置 workspaces 字段，指定包含子包的目录路径。执行 npm install 时，npm 会自动解析这些子包并建立链接，使得子包之间可以互相引用且共享依赖。这种机制避免了手动创建符号链接或重复安装依赖，实现了单一仓库内的多包协同开发。
如何定义工作区结构
在根目录的 package.json 中添加 workspaces 数组即可定义工作区。该数组支持 glob 模式，例如 "packages/*" 会匹配 packages 目录下所有的一级子文件夹作为独立的工作区。每个子文件夹必须拥有自己的 package.json 文件，其中定义了该包的名称、版本和入口点。根目录的 package.json 通常不包含业务代码，仅作为元数据管理和脚本调度中心。
{
"name": "root-project",
"private": true,
"workspaces": [
"packages/*"
],
"scripts": {
"build": "npm run build --workspaces"
}
}上述配置假设项目结构如下：packages/utils 和 packages/core 是两个独立的包。当运行 npm install 时，npm 会在根目录的 node_modules 中创建一个 @scope/package-name 或裸名的符号链接，指向实际的子包目录。这样，其他子包可以通过 import { func } from 'utils-package' 直接引入，无需发布到公共仓库。
立即学习“Java免费学习笔记（深入）”；
如何在子包间共享依赖
工作区允许子包声明对同一依赖的不同版本需求，npm 会尝试扁平化依赖树以节省空间，但在某些情况下（如版本冲突）会保留嵌套结构。开发者可以在子包的 package.json 中直接引用其他工作区包，使用版本号 1.0.0 或通配符 *。npm 在安装时会将这些引用解析为本地文件系统路径，确保修改一个包后，依赖它的包能立即看到更新（需重新构建或重启服务）。
// packages/core/package.json
{
"name": "@myorg/core",
"version": "1.0.0",
"dependencies": {
"@myorg/utils": "*"
}
}
// packages/utils/package.json
{
"name": "@myorg/utils",
"version": "1.0.0"
}运行 npm install 后，@myorg/core 的 node_modules 中将出现一个指向 ../../packages/utils 的符号链接。这意味着两个包共享同一个 @myorg/utils 实例。如果根目录也声明了某个依赖，子包未声明该依赖但需要使用时，npm 会从父级向上查找，实现依赖提升。这种机制简化了大型项目的依赖管理，避免了版本不一致导致的运行时错误。
workspace 命令如何筛选特定包
在使用 npm run 或 npm test 等命令时，默认行为是遍历所有工作区执行。若只想针对特定包运行脚本，可以使用 --workspace 或 -w 标志。例如，npm run build -w @myorg/core 仅构建 @myorg/core 包，忽略其他包。这对于微服务或多模块项目中只关注局部变更的场景非常有用，能显著减少 CI/CD 流水线的时间消耗。
npm run lint -w packages/utils npm test -w @myorg/core -- --coverage
上述命令展示了如何通过 -w 参数精确控制执行范围。第一个命令仅在 packages/utils 中运行 lint 脚本，第二个命令在 @myorg/core 中运行测试并生成覆盖率报告。这种细粒度控制使得开发者可以在不干扰整个工作区的情况下，快速验证单个包的改动。同时，npm ls 命令也可以配合 -w 查看特定包的依赖树，帮助排查依赖冲突问题。
