跳到主要内容

pnpm Workspace 命令速查 — 60+ 条 Monorepo 开发命令

可搜索的 pnpm workspace 速查,60+ 条命令覆盖 filter 语法、workspace 协议、递归脚本和 monorepo 常见坑。

  • 本地处理
  • 分类 开发运维
  • 适合 格式化、校验、压缩或检查和代码相关的文本。
分类:
60 条命令
pnpm · 配置 (7)
pnpm-workspace.yaml

根目录配置文件,声明哪些目录是 workspace 包。`packages:` 下的 glob 模式选中所有匹配目录。

输入
packages:
  - "packages/*"
  - "apps/*"
  - "!**/__tests__/**"
输出
(all subdirs of packages/ and apps/ become workspace packages)

⚠ 常见坑: 这个文件必须放在 workspace 根目录(和根 package.json 同层)。放进子目录会静默失效。

例子
# pnpm-workspace.yaml
packages:
  - "packages/*"
  - "apps/*"
# include a specific path too
packages:
  - "packages/*"
  - "tools/codegen"
pnpm init (at workspace root)

初始化 workspace 根目录的 package.json。立即加上 `"private": true`——根目录不该发布到 npm。

⚠ 常见坑: 根目录忘写 `"private": true` 的话,`pnpm publish` 可能会误把 monorepo 根目录发布出去。

例子
pnpm init
# then add to package.json:
# "private": true
# root package.json minimum
{
  "name": "my-monorepo",
  "private": true,
  "version": "0.0.0"
}
catalog: (pnpm-workspace.yaml, pnpm 9+)

Catalog 在 pnpm-workspace.yaml 里统一锁定共享依赖版本。子包用 `catalog:` 代替版本字符串引用它。

输入
catalog:
  react: "^18.3.0"
  typescript: "^5.4.0"
# package.json in any workspace pkg:
# "react": "catalog:"
输出
(all packages using "catalog:" get the same pinned version)

⚠ 常见坑: catalog: 需要 pnpm 9+。pnpm 8 及更老版本会静默忽略该字段,包拿不到版本约束,安装会出问题。

例子
# pnpm-workspace.yaml
catalog:
  react: "^18.3.0"
  vite: "^5.0.0"
# packages/ui/package.json
"dependencies": {
  "react": "catalog:"
}
shamefully-hoist=true (.npmrc)

让 pnpm 把所有传递依赖提升到根 node_modules,行为和 npm/yarn 一样。用于兼容那些不声明依赖就去 node_modules 找包的老工具。

⚠ 常见坑: shamefully-hoist 会把幽灵依赖问题藏起来。优先用 `public-hoist-pattern[]=<包名>` 只提升出问题的那个包。

例子
# .npmrc
shamefully-hoist=true
# Better: only hoist the specific package
# .npmrc
public-hoist-pattern[]=*eslint*
public-hoist-pattern[]=*prettier*
node-linker=hoisted (.npmrc)

shamefully-hoist 的替代方案。使用扁平提升的 node_modules 布局,不是完全提升——兼容性的折中。

例子
# .npmrc
node-linker=hoisted
# also useful for Next.js / Vercel deployments
# node-linker=hoisted
# strict-peer-dependencies=false
pnpm install (workspace root)

在根目录一条命令安装 workspace 里所有包的依赖。

例子
pnpm install
# CI: fail if lockfile would change
pnpm install --frozen-lockfile
pnpm workspace --help

打印内置 workspace 命令帮助。用于了解有哪些子命令。

例子
pnpm workspace --help
pnpm --help | grep filter
pnpm · 过滤 (13)
pnpm --filter <package-name> <cmd>

只在 package.json 的 `name` 字段精确匹配的包里跑命令。最常用的 filter 形式。

例子
pnpm --filter @myapp/ui run build
pnpm --filter my-backend run start:dev
pnpm --filter "./<dir>" <cmd>

按相对于 workspace 根目录的路径过滤。必须加前置 `./` 以区分路径和包名。

例子
pnpm --filter "./apps/web" run dev
pnpm --filter "./packages/*" run test
pnpm --filter "{./packages/**}" <cmd>

用 glob 按目录路径过滤。pnpm filter 语法里用花括号包裹路径 glob。

例子
pnpm --filter "{./packages/**}" run lint
pnpm --filter "{./apps/*}" run build
pnpm --filter <pkg>... <cmd>

后置 `...` 选中该包及其所有传递依赖。适合重新构建一个包及其所有依赖项。

⚠ 常见坑: `...` 是 filter 字符串的一部分,不是 shell glob。要加引号防止 shell 展开: `--filter "myapp..."` 或 `--filter 'myapp...'`。

例子
pnpm --filter "@myapp/ui..." run build
pnpm --filter 'my-api...' run test
pnpm --filter ...^<pkg> <cmd>

选出所有依赖 `<pkg>` 的包(消费者)。修改共享库后用这个重新测试所有引用了它的包。

例子
pnpm --filter '...^@myapp/utils' run test
pnpm --filter '...^@myapp/ui' run build
pnpm --filter "[<git-ref>]" <cmd>

选出自给定 git ref 以来有文件变更的包。方括号表示基于 git diff 的过滤器。

例子
pnpm --filter "[main]" run build
pnpm --filter "[HEAD~1]" run test
pnpm --filter "[origin/main]" run lint
pnpm --filter "...[<git-ref>]" <cmd>

选出 git ref 之后有变更的包及其所有依赖方。重新构建所有可能受 diff 影响的包——标准 CI 模式。

⚠ 常见坑: 没有前置 `...` 的话,只有变更包本身跑——依赖它们的包可能带着崩掉的依赖发布出去。

例子
pnpm --filter "...[origin/main]" run build
# GitHub Actions example:
pnpm --filter "...[origin/${{ github.base_ref }}]" run test
pnpm --filter <a> --filter <b> <cmd>

多个 --filter 标志取并集(OR):命令在匹配 filter a 或 filter b 的包里都跑。

例子
pnpm --filter @myapp/ui --filter @myapp/utils run lint
pnpm --filter "./apps/*" --filter "@myapp/shared" run build
pnpm --filter !<package-name> <cmd>

从过滤结果中排除某个特定包。`!` 取反匹配。

例子
pnpm --filter !@myapp/docs run build
pnpm -r --filter !legacy-package run test
pnpm ls --filter <package-name>

列出单个 workspace 包的依赖树。

例子
pnpm ls --filter @myapp/ui
pnpm ls --filter @myapp/ui --depth 2
pnpm --filter "@myapp/*" <cmd>

用通配符过滤某个 scope 下的所有包。匹配所有名字以 @myapp/ 开头的包。

例子
pnpm --filter "@myapp/*" run lint
pnpm --filter "@mycompany/*" run build
pnpm --filter <pkg> --filter <dep> <cmd>

在指定的包和某个依赖里同时跑命令。适合一次性构建一个库和它的消费包。

例子
pnpm --filter @myapp/utils --filter @myapp/web run build
pnpm ls --recursive

递归列出所有 workspace 包的依赖。帮助审计哪里安装了什么。

例子
pnpm ls --recursive
pnpm ls -r --depth 0   # top-level only
pnpm · 安装 (9)
pnpm add <pkg> --filter <workspace-pkg>

在仓库任意位置给某个 workspace 包加依赖——不需要 cd 进去。

⚠ 常见坑: 在 workspace 根目录省略 --filter 会把依赖加到根 package.json,不是子包。通常是误操作。

例子
pnpm add react --filter @myapp/ui
pnpm add -D typescript --filter @myapp/utils
pnpm add lodash --filter "./packages/helpers"
pnpm add -w <pkg>

把依赖加到 workspace 根目录(`-w` / `--workspace-root`)。适合 eslint、prettier、turbo 这类共享开发工具。

⚠ 常见坑: 根目录通常不需要生产依赖。大多数根 package.json 都是 `"private": true`,运行时依赖应该加到具体子包里。

例子
pnpm add -Dw eslint prettier typescript turbo
pnpm add -Dw vitest
pnpm install --frozen-lockfile

如果锁文件需要更新就报错退出,而不是静默修改。CI 里必须加这个参数,用于检测未同步的锁文件。

⚠ 常见坑: CI 里不加 --frozen-lockfile 的话,开发者忘记提交更新后的锁文件时,CI 会静默安装和本地不同的版本。

例子
# In CI (GitHub Actions, etc.)
pnpm install --frozen-lockfile
# Also equivalent:
pnpm ci
pnpm install --ignore-workspace

只安装根目录自身的依赖,跳过所有子包。很少用到;适合只需要安装根目录工具的步骤。

例子
pnpm install --ignore-workspace
pnpm update --filter <pkg> <dep>

把单个 workspace 包里某个依赖更新到允许范围内的最新版本。

例子
pnpm update --filter @myapp/ui react
pnpm update --filter @myapp/api --latest
pnpm update -r

把所有 workspace 包里的依赖更新到各自 package.json 版本范围内的最新版本。

⚠ 常见坑: pnpm update -r 之后始终跑全量测试。批量更新可能让包之间潜在的不兼容问题浮出水面。

例子
pnpm update -r
pnpm update -r --latest   # ignore semver ranges
pnpm why <pkg> --filter <workspace-pkg>

显示某个包被安装进指定 workspace 包的原因——是哪条依赖链把它带进来的。

例子
pnpm why lodash --filter @myapp/web
pnpm why esbuild --filter @myapp/build
pnpm dedupe

对 workspace 各包的依赖版本去重,减少锁文件中的包数量。

例子
pnpm dedupe
# check what would be deduped without changing anything:
pnpm dedupe --check
pnpm remove <pkg> --filter <workspace-pkg>

从指定 workspace 包里移除依赖并更新其 package.json。

例子
pnpm remove lodash --filter @myapp/utils
pnpm remove -D eslint --filter @myapp/web
pnpm · 脚本 (9)
pnpm -r run <script>

在所有定义了该脚本的 workspace 包里递归跑脚本。`-r` 是 `--recursive` 的缩写。

⚠ 常见坑: pnpm -r run 在任何一个包的脚本失败时就退出非零。用 --if-present 跳过没有该脚本的包,而不是报错。

例子
pnpm -r run build
pnpm -r run test
pnpm -r run lint
pnpm -r run <script> --if-present

递归跑脚本,但静默跳过没有定义该脚本的包。适合各包脚本不统一的 monorepo。

例子
pnpm -r run build --if-present
pnpm -r run generate --if-present
pnpm run --filter <pkg> <script>

在指定 workspace 包里跑脚本。等价于 cd 进包目录再跑 `pnpm run <script>`。

例子
pnpm run --filter @myapp/web dev
pnpm run --filter @myapp/api start
pnpm -r run <script> --parallel

所有包并行跑脚本,不考虑依赖图顺序。独立任务更快;如果各包的构建产物互相依赖则危险。

⚠ 常见坑: 加了 --parallel,pnpm 会同时构建 A 和 B,即使 B 依赖 A。如果 B 的构建在 A 完成前就开始了,B 会失败。有构建顺序依赖时不要加 --parallel。

例子
pnpm -r run test --parallel
pnpm -r run lint --parallel
pnpm -r run <script> --stream

把所有包的输出实时交错打印到终端,每行加包名前缀。不加 --stream 时默认是每个包缓冲后按顺序打印。

例子
pnpm -r run dev --stream
pnpm -r run test --stream --parallel
pnpm exec --filter <pkg> <cmd>

在指定包的目录下执行 shell 命令,该包的 node_modules/.bin 会加进 PATH。

例子
pnpm exec --filter @myapp/web tsc --noEmit
pnpm exec --filter @myapp/api prisma migrate dev
pnpm -r exec <cmd>

在每个 workspace 包目录里递归执行 shell 命令。

例子
pnpm -r exec -- node -e "console.log(process.env.npm_package_name)"
pnpm -r exec rm -rf dist
pnpm --filter <pkg> run <script> -- --arg

用 `--` 分隔符给包脚本传额外参数。`--` 之后的内容都会转发给脚本。

例子
pnpm --filter @myapp/web run build -- --mode production
pnpm --filter @myapp/api run test -- --watch
pnpm -r run build --workspace-concurrency 4

限制并行构建的包数量。默认是 4。CI 机器内存紧张时适当调小。

例子
pnpm -r run build --workspace-concurrency 2
pnpm -r run test --workspace-concurrency 1   # serial
pnpm · 协议 (7)
"dep": "workspace:*"

引用本地 workspace 包,发布时解析为该包 package.json 里的精确版本。最适合不发布到 npm 的应用。

输入
# package.json of packages/web
"dependencies": {
  "@myapp/ui": "workspace:*"
}
输出
# After `pnpm changeset publish` replaces workspace: refs:
"@myapp/ui": "2.1.0"
例子
"@myapp/ui": "workspace:*"
"@myapp/utils": "workspace:*"
"dep": "workspace:^"

发布时解析为 `^X.Y.Z` 的 caret 范围,使用本地版本号。适合要发布、且依赖兄弟包的库。

输入
"@myapp/utils": "workspace:^"
# @myapp/utils is currently at 3.0.0
输出
"@myapp/utils": "^3.0.0"   # in published package.json

⚠ 常见坑: 可发布的库用 workspace:* 的话,发布出去的是 `"dep": "精确版本号"`(没有 caret)。消费者被锁定在这个精确版本,拿不到自动的 patch 更新。

例子
"@myapp/types": "workspace:^"
"@myapp/core": "workspace:^"
"dep": "workspace:~"

发布时解析为 tilde 范围 `~X.Y.Z`——只允许 patch 更新,不允许 minor。比 workspace:^ 更保守。

例子
"@myapp/config": "workspace:~"
"dep": "workspace:1.2.3"

指定一个精确版本号,该版本必须是 workspace 包的当前版本。很少需要;大多数情况优先用 workspace:*。

例子
"@myapp/legacy": "workspace:1.0.0"
pnpm pack (with workspace: replaced)

pnpm pack 打包时会自动把 workspace: 协议引用替换成解析后的版本字符串——不需要手动操作。

例子
# From the package directory:
pnpm pack
# Inspect the tarball to verify resolved deps:
tar -tf my-package-1.0.0.tgz
pnpm link --filter <pkg> --global

把 workspace 包全局链接,让 monorepo 外部的其他项目在开发期间也能用到本地版本。

⚠ 常见坑: 全局链接不被 git 追踪,团队成员克隆仓库后就失效了。包间引用应该用 workspace 协议,全局链接只是个人开发的临时手段。

例子
pnpm link --filter @myapp/utils --global
# Then in the consumer project:
pnpm link --global @myapp/utils
pnpm pack --filter <pkg>

为指定 workspace 包打一个 .tgz 压缩包,检查实际要发布的内容,包括解析后的 workspace: 引用。

例子
pnpm pack --filter @myapp/utils
# Inspect the tarball:
tar -tzf myapp-utils-1.0.0.tgz | head -30
pnpm · 发布 (6)
pnpm changeset

创建变更集文件,描述改了什么和预期版本升级类型(major / minor / patch)。开包含用户可见改动的 PR 时跑这个。

⚠ 常见坑: changesets 需要在 workspace 根目录安装 @changesets/cli。用 `pnpm add -Dw @changesets/cli` 添加。

例子
pnpm changeset
# interactive CLI: select packages, bump type, and description
# or with --empty for a no-bump changeset:
pnpm changeset --empty
pnpm changeset version

消费所有待处理的变更集文件,更新 package.json 版本号并更新 CHANGELOG.md。在合并发版 PR 后跑。

例子
pnpm changeset version
# Preview what would change:
pnpm changeset status
pnpm changeset publish

把所有版本有变更的包发布到 npm。先为每个包执行 `pnpm build`(或配置的 publish 脚本)。

⚠ 常见坑: 需要 npm 登录(`npm login`)或设置 NPM_TOKEN 环境变量。否则 publish 报 401 Unauthorized。

例子
pnpm changeset publish
# dry-run to see what would publish:
pnpm changeset publish --dry-run
pnpm publish --filter <pkg>

不通过 changesets 把单个 workspace 包发布到 npm。适合手动发布热修复。

例子
pnpm publish --filter @myapp/utils
pnpm publish --filter @myapp/utils --access public --no-git-checks
pnpm -r publish --access public

把所有 workspace 包发布到 npm,全部设为 public 访问权限。带 scope 的包(@scope/name)默认是 restricted,需要这个参数。

⚠ 常见坑: 带 scope 的包(@myorg/pkg)在 npm 上默认是私有的。不加 `--access public` 会收到 402 Payment Required 报错。

例子
pnpm -r publish --access public
pnpm -r publish --access public --no-git-checks
pnpm version --filter <pkg> <bump>

给单个 workspace 包升版本(patch / minor / major)。把新版本号写入 package.json。

例子
pnpm version --filter @myapp/utils patch
pnpm version --filter @myapp/api minor
pnpm · 常见坑 (9)
Phantom dependencies in strict mode

pnpm 默认的严格 node_modules 布局要求包只能导入自己 package.json 里明确声明的依赖。导入未声明的传递依赖会在运行时报 MODULE_NOT_FOUND 错误。

⚠ 常见坑: 如果 `import "some-package"` 在 npm 项目里能用但在 pnpm 里失败,那就是幽灵依赖。修法是把 `some-package` 加到对应包的 devDependencies 里。不要用 shamefully-hoist 掩盖问题。

例子
# To find which package actually owns some-package:
pnpm why some-package --filter @myapp/web
Lockfile version conflict on pnpm upgrade

pnpm 锁文件格式在大版本之间会变。升级 pnpm 后,先跑 `pnpm install` 用新格式重新生成锁文件再提交。

⚠ 常见坑: 升级 pnpm 后提交旧格式的锁文件,会导致每个团队成员(和 CI)在重新生成锁文件之前都遇到 "ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY" 或格式不匹配的报错。

例子
# After upgrading pnpm:
pnpm install
git add pnpm-lock.yaml
git commit -m "chore: regenerate lockfile for pnpm vX"
Package not found after rename

重命名 workspace 包(修改其 package.json 里的 `name`)后,如果没有同步更新兄弟包里的 `workspace:` 引用,安装就会报错。

⚠ 常见坑: pnpm install 会报 "No matching version found for @old/name",因为 workspace 协议按名字而不是目录路径查找包。

例子
# After renaming @myapp/foo to @myapp/bar:
# 1. Update all "workspace:*" refs from @myapp/foo → @myapp/bar
# 2. pnpm install
# grep to find all stale references:
grep -r "@myapp/foo" packages/ apps/
peer dependency warnings in workspace

pnpm 比 npm 更积极地报 peer 依赖问题。`WARN … peer dependencies unmet` 消息可能不会中断构建,但可能说明真实的兼容性问题。

⚠ 常见坑: 在 .npmrc 里设 `strict-peer-dependencies=false` 能关掉警告但不解决根本问题。关掉之前先排查一下。

例子
# To silence peer dep warnings globally (use sparingly):
# .npmrc
strict-peer-dependencies=false
# To see what peer deps are unmet:
pnpm ls --depth 1 --filter @myapp/web
"workspace:*" in publishable package

在要发布到 npm 的包里用 `workspace:*`,消费者拿到的是 `"dep": "1.2.3"`(精确锁定)。他们无法自动拿到 patch 更新——改用 `workspace:^`。

例子
# Wrong for published libs:
"@myapp/utils": "workspace:*"
# Right for published libs:
"@myapp/utils": "workspace:^"
pnpm run at wrong cwd

在 workspace 根目录跑 `pnpm run dev` 本意是跑某个子包的 dev,结果跑的是根目录的 dev 脚本(往往没有定义)。

⚠ 常见坑: 如果根目录没有 `dev` 脚本,会报 "ERR_PNPM_NO_SCRIPT"。要么加 `--filter`,要么先 cd 进包目录。

例子
# Always use --filter from root:
pnpm run --filter @myapp/web dev
# Or cd first:
cd apps/web && pnpm run dev
Missing --frozen-lockfile in CI

CI 里跑普通 `pnpm install` 允许 pnpm 在 package.json 有偏差时静默更新锁文件。自动化流水线里始终要用 `pnpm install --frozen-lockfile` 或 `pnpm ci`。

例子
# .github/workflows/ci.yml
- run: pnpm install --frozen-lockfile
# equivalent shorthand:
- run: pnpm ci
pnpm catalog: on pnpm < 9

pnpm < 9 里 package.json 里的 `catalog:` 说明符会被静默当成未知版本——包要么没有版本约束地安装,要么直接安装失败。

⚠ 常见坑: 采用 catalog: 之前先检查 `pnpm --version`。如果团队或 CI 的 pnpm 版本不统一,在根 package.json 的 `engines.pnpm` 字段里强制最低版本。

例子
# root package.json
"engines": {
  "pnpm": ">=9.0.0"
}
# Also add to .npmrc:
engine-strict=true
Turborepo cache stale after dep change

如果配合 Turborepo 使用 pnpm workspace,重命名包或修改 workspace: 引用会让 turbo 的依赖图哈希失效。结构性修改后跑 `turbo run build --force` 强制清缓存。

例子
turbo run build --force
# Or delete the .turbo directory:
rm -rf .turbo && turbo run build

这个工具能做什么

可搜索的 pnpm workspace 速查,60+ 条命令,覆盖日常 monorepo 开发 会遇到的所有操作。Setup 部分:创建 pnpm-workspace.yaml 配置 glob 模式、 用 pnpm 9+ 的 catalog 功能锁定共享依赖版本、用 shamefully-hoist 兼容不符合严格 模式的旧工具。Filter 部分(workspace 最核心的用法):--filter 按包名、目录路径、 git diff、依赖图选包;^pkg 加所有依赖它的包;pkg... 加它的所有依赖;...pkg 加所有 依赖它的包;多个 --filter 组合;按 git ref 过滤有变更的文件。Install 部分:在 workspace 根目录执行 pnpm install、CI 用 --frozen-lockfile、用 --filter 给单个包 加依赖、workspace 级安装和包级安装的区别。Scripts 部分:pnpm run --filter 指定包 跑脚本、pnpm -r run 在所有包递归跑、--parallel 和 --stream 标志、--if-present 跳过 没有该脚本的包、按依赖图排序执行。Publish 部分:changesets 工作流(add → version → publish)、pnpm publish --filter、版本号管理、access 和 registry 参数。Protocol 部分:package.json 里的 workspace:*、workspace:^、workspace:~,publish 时的解析规则, 各自的适用场景。Link 部分:pnpm link 和 workspace 协议的对比、--global 标志、什么 时候本地链接比 workspace 更好用。Pitfall 部分:hoist 踩坑、strict 模式下的幽灵依赖、 .npmrc 关键配置、CI frozen-lockfile 的坑、包改名后找不到催化包、pnpm catalog 的 注意事项、锁文件版本冲突。每条都给中英双语说明、可直接拷贝的例子和真实 输入/输出。搜索框跨命令/说明/例子/坑文本四个字段同时过滤。完全本地运行, 离线可用。

工具细节

输入
文本
页面会根据工具类型展示文本框、数值控件、文件选择或结构化输入。
输出
即时结果 + 复制 + 预览
结果区优先给出可操作结果，支持项会显示复制、下载或可视化预览。
隐私
浏览器本地处理
主工具逻辑未发现外部 API 调用，输入通常留在当前标签页内处理。
保存 / 分享
可分享链接状态
关键设置会进入 URL，复制链接后别人能复现同一组参数。
性能预算
首屏 JS ≤ 28 KB
没有声明 WASM 依赖，适合快速打开和移动端使用。
适用场景
开发运维 · 程序员
分类和职业标签用于推荐相关工具、组织内链，并帮助用户快速判断是否适合当前任务。

怎么用

  1. 1. 输入

    把内容粘贴或拖入工具面板。

  2. 2. 处理

    点击按钮,在浏览器内本地处理,文件不上传。

  3. 3. 复制 / 下载

    一键复制结果或下载到本地。

pnpm Workspace 命令速查 适合怎么用

适合穿插在写代码、查问题、做 Review、上线前的小任务里。

适合开发场景

  • 格式化、校验、压缩或检查和代码相关的文本。
  • 把片段整理好再放进文档、工单、提交或交接材料。
  • 不切换工具,快速检查一个小 payload。

开发检查项

  • 压缩、混淆这类不可逆处理,先对副本操作。
  • 除非确认工具本地处理,不要粘贴密钥和敏感片段。
  • 转换后的代码上线前,仍要跑自己的测试或 lint。

下一步可以接着做

这些入口会把当前任务接到更完整的工具链里。

  1. 1 npm / yarn / pnpm 命令速查 npm / yarn / pnpm 命令速查,80+ 条覆盖 init/install/scripts/publish,三个工具对照表。 打开
  2. 2 package.json 速查表 package.json 字段速查,55+ 字段配真实示例,双语可搜索。 打开
  3. 3 Git 命令速查 Git 命令速查：可搜可分类，每条带说明、常见坑、真实例子。 打开

真实使用场景

  • 在 CI 里只重新构建 PR 影响到的包

    monorepo 有 40 个包,全量构建要 12 分钟。你在 GitHub Actions 的 pull_request 事件里接 `pnpm --filter "...[origin/main]" run build`。只有 2 个变更包和 3 个依赖它们的包跑构建，CI 时间降到 90 秒。filter 部分的 git-ref 模式和 `...` 依赖方语法是实现这件事的关键。

  • 添加一个共享 ESLint 配置,避免 hoist 踩坑

    你想让所有包共用一套 @myapp/eslint-config。在每个包的 devDependencies 里写 `"@myapp/eslint-config": "workspace:*"`,在 packages/eslint-config 建好配置包, 在 workspace 根目录跑 `pnpm install`。workspace 协议速查条目加上幽灵依赖那条 坑帮你绕过最常见的问题。

  • 只发布一个库的 major 版本,不动其他包

    要发布带 breaking change 的 @myapp/utils@2.0.0,同时不动 @myapp/ui 的 1.x。 跑 `pnpm changeset`,只给 utils 选 "major",再跑 `pnpm changeset version`。 只有 utils/package.json 升到 2.0.0,依赖它的应用包通过 changeset 工具自动 更新到 workspace:^2.0.0 范围。publish 部分覆盖每个步骤。

常见踩坑

  • 在 workspace 根目录跑 `pnpm add lodash` 却本意是加到某个子包。应该加 `--filter` 或先 cd 进包目录。

  • 给要发布的库用 `workspace:*`。发布后 consumers 拿到的是精确锁定的版本号,无法自动拿到 patch 更新，可发布的库应该用 `workspace:^`。

  • CI 里忘了加 `--frozen-lockfile`。没有它,pnpm 在 package.json 有偏差时会静默修改锁文件,把依赖漂移的 bug 藏到生产环境才暴露。

隐私说明

所有命令、搜索框、分类过滤和复制按钮全部在浏览器里跑,对着内存里的 JavaScript 数组。命令文本、搜索词、剪贴板内容都不会发到服务器,也不会写进 URL。打开 DevTools → Network 边输入边看:零出站请求。飞机上或离网跳板机上都能用。

常见问题

类似工具组合

做你这行的人, 还会一起用这些。

看这个职业的全部工具
Made by Toolora · 100% client-side · Updated 2026-07-01