Rush.js 靠 rush install 和 .vscode/settings.json 协同生效，VSCode 不理解 Rush，只识别 TypeScript 配置、路径别名等；需在子包运行 rush install、配置正确 tsconfig.json 的 baseUrl/paths、使用本地 TS 版本、排除无关目录监视，并推荐打开子包而非根目录。
直接上结论：Rush.js 不是靠 VSCode 插件“配置”出来的，而是靠 rush install 和工作区级 .vscode/settings.json 协同生效的；VSCode 本身不理解 Rush，它只认 TypeScript、npm link、路径别名和文件监视规则——这些才是你真正要调的点。
为什么 rush install 后 VSCode 还报“找不到模块”
Rush 管理的是 monorepo 内部的符号链接（common/temp/node_modules），但 VSCode 的 TypeScript 语言服务默认只读取项目根下的 node_modules，不会自动跟随 Rush 创建的软链。结果就是 import 路径标红、跳转失败、类型推导失效。
- 必须在每个子包（如
apps/my-app或libraries/my-lib）的根目录下运行rush install，而不是只在仓库根运行一次 - 确保子包里有有效的
tsconfig.json，且"baseUrl": "."和"paths"配置与rush.json中的projects列表对齐 - VSCode 右下角显示的 TypeScript 版本必须是项目本地的（如
5.4.5），不是 “Bundled”——否则整个类型系统脱节
如何让 VSCode 正确识别 Rush 的路径别名
Rush 本身不生成路径映射，它靠 common/config/rush/rush-plugins.json 和 common/config/typescript/ 下的共享配置来统一管理。VSCode 要识别 @myorg/my-lib 这类包名，关键在子包自己的 tsconfig.json：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
"compilerOptions.paths必须显式声明，例如："@myorg/*": ["../libraries/*/src"]，不能依赖 Rush 自动注入 -
"include"至少包含["src/**/*", "src/**/*.d.ts"]，漏掉.d.ts会导致类型声明不被加载 - 如果用 Vite 或 Webpack 构建，它们的
resolve.alias是运行时行为，VSCode 不认——所以编辑器路径补全、跳转完全依赖 TS 的paths
大型 Rush 仓库下 VSCode 卡顿的根源与对策
卡顿从来不是 Rush 导致的，而是 VSCode 默认监视整个工作区（含 common/temp、node_modules、dist）触发了系统 inotify 限制或内存爆满。
立即学习“前端免费学习笔记（深入）”；
- 在仓库根目录的
.vscode/settings.json中强制排除："files.watcherExclude": { "**/common/temp/**": true, "**/node_modules/**": true, "**/dist/**": true } - 禁用 workspace 级 GitLens（不是卸载，是右键 → Disable (Workspace)），它在 10k+ 文件仓库里会持续扫描 .git/index
- 添加
"typescript.preferences.includePackageJsonAutoImports": "auto"，避免 TS 语言服务盲目索引所有依赖包的 types
最常被忽略的一点：Rush 项目不该用 VSCode 直接打开整个仓库根目录，而应打开具体子包（如 apps/my-web-app）作为独立工作区——这样 tsconfig.json、package.json 和文件监视范围才自然对齐，VSCode 才不会“以为自己在管一个巨型单体”。
