VSCode本身不内置Lerna支持，核心是确保路径、符号解析和执行上下文对齐：终端需加载node_modules/.bin路径（推荐npx调用），tasks.json须显式指定cwd为根目录，TS跳转依赖tsconfig.base.json中paths映射及重启TS服务。
VSCode 本身不内置 Lerna 支持，所有“配置”本质是让终端、任务、跳转、类型检查在 monorepo 环境下正常工作——核心问题不是装插件，而是路径、符号解析和执行上下文对齐。
VSCode 终端里 lerna 命令报 command not found
根本原因不是没装 Lerna，而是 VSCode 启动的终端 shell 没加载项目 node_modules/.bin 路径，尤其当你用 pnpm/yarn 管理 monorepo 时，lerna 只装在根目录，但 shell 的 PATH 里没有它。
- 先在项目根目录运行
npx lerna --version，如果成功，说明 Lerna 已安装，纯属路径缺失 - 检查 VSCode 设置里
terminal.integrated.defaultProfile是否指向你日常用的 shell（如zsh或bash），Windows 用户常误设为 PowerShell，导致环境变量不一致 - 不要改全局
~/.zshrc加./node_modules/.bin—— 这只对当前目录有效且有安全风险；更稳妥的做法是统一用npx lerna执行命令 - 如果坚持用全局命令，确保 Lerna 是本地安装（
npm install lerna --save-dev），而非仅全局安装（npm install -g lerna），因为 monorepo 中各包可能依赖不同版本
想点一下就跑 lerna bootstrap 或 lerna run build
VSCode 的 tasks.json 可以绑定 Lerna 命令，但硬写 lerna bootstrap 会失败：它依赖正确的 cwd 和 node_modules 上下文，而 VSCode 默认从打开的文件夹启动任务，不一定在根目录。
- 在项目根目录创建
.vscode/tasks.json，内容用type: "shell"+command: "npx lerna bootstrap"，并显式指定options.cwd为"${workspaceFolder}" - 若要针对某包运行脚本（如只构建
packages/ui），加--scope=ui参数：npx lerna run build --scope=ui - 避免在
dependsOn里手动写跨包依赖——Lerna 自己靠lerna.json的commands配置或隐式拓扑决定执行顺序，VSCode 任务不参与该逻辑 - 把
group设为"build"或"test"，这样按Ctrl+Shift+B（macOS 是Cmd+Shift+B）就能唤出对应菜单
Ctrl+Click 跳转不到本地包（比如 import { foo } from 'my-utils'）
这是 TypeScript + monorepo 最典型的符号解析断裂。VSCode 的 TS 语言服务默认只查 node_modules，但 Lerna 的本地包（如 my-utils）是通过软链（symlink）或 paths 映射暴露的，TS 不知道去哪找源码。
- 确认根目录有统一的
tsconfig.base.json，并在每个包的tsconfig.json里用"extends": "../tsconfig.base.json" - 在
tsconfig.base.json的compilerOptions.paths中配好映射，例如："my-utils": ["packages/my-utils/src"]（注意路径必须是相对于baseUrl，通常设为"."） - 别依赖 Lerna 的
bootstrap自动生成软链后让 TS 自动识别——有些编辑器缓存不刷新，重启 TS 服务（Ctrl+Shift+P → "TypeScript: Restart TS server"）比等自动修复更可靠 - 如果用 pnpm，确保启用了
node-linker: pnpm（默认），它生成的链接更稳定；yarn v1 需开linker: node-modules并配合yarn link，但易出错
真正卡住人的从来不是“怎么配”，而是 PATH、cwd、tsconfig 三者没对齐——任何一个错位，VSCode 就会表现得像“不支持 Lerna”。调试时优先验证 npx lerna list 和 npx tsc --noEmit 是否都成功，再谈其他。
