常见问题解答 (FAQ)
我的所有项目都在一个大的仓库中?这是一个好主意吗?
在 这篇文章 中得到解答。
我应该将错误报告或功能请求发送到哪里?
为 **rushstack** 项目打开一个 GitHub 问题。在你的问题标题中包含“Rush”。
在同一个仓库中有多个项目,"npm install" 会不会花费太长时间?
你可能在想:“嗯... 如果我现在的安装需要 3 分钟,而你要我将 20 个项目放在一个仓库中,难道不会将我的 NPM 安装时间乘以 20 倍,达到 60 分钟吗?” 不会。Rush 将你的依赖项集中在一个 "common" 文件夹中,并只运行一次 "npm install",安装时间与你原来的单体应用程序基本相同。
Rush 会使我的工具变得不标准吗?
不会!Rush 在现有系统和标准内工作。它只是让事情做得更好更快。
- 每个项目文件夹仍然是自包含的(没有模糊包边界)
- 仍然可以无需 Rush 构建任何项目;只需像往常一样运行
pnpm install
和npm run build
(虽然 package.json 中的workspace:*
引用 可能需要移除) - 任何时候都可以将项目移到另一个仓库,无需任何代码更改;没有承诺!
"Rush Stack" 和 Rush 是同一回事吗?
不。**Rush Stack** 是一个项目套件,由一群开发人员维护,他们的共同目标是为大型 TypeScript 单体仓库构建专业工具。Rush 是 Rush Stack 的一部分。其他部分是完全可选的。Rush 本身是工具链无关的——它作为独立工具效果很好。有关更多详细信息,请查看 Rush Stack 网站。
安装 Rush 后,为什么我仍然看到旧版本?
这个问题并非 Rush 特有,但我们经常听到这个问题,因为 Rush 是人们在开始工作时需要调用的第一个工具之一。症状如下
C:\> npm install -g @microsoft/rush
C:\Program Files\nodejs\rush -> C:\Program Files\nodejs\node_modules\@microsoft\
rush\bin\rush
C:\Program Files\nodejs
`-- @microsoft/rush@3.0.1
C:\> rush
Rush Multi-Package Build Tool 2.5.0 - http://aka.ms/rush
NPM 似乎说它正在安装 3.0.1 版本,但是当我们执行命令时,它显示 Rush 版本 2.5.0。这是怎么回事?
问题在于,当你键入诸如 "heft" 或 "rush" 之类的命令时,它们会在你的系统 PATH 中找到,而 PATH 可能指向来自先前安装的 NodeJS 或 NPM 的文件夹。
解决方法
- 运行
npm ls -g --depth 0
找出你的 NPM 包安装在哪里。 - 运行
set
命令并检查你的 PATH 环境变量。 - 确保来自 #1 的文件夹之前的 PATH 中没有其他 NPM 或 NodeJS 文件夹
- 删除 PATH 中的任何旧文件夹,例如来自 NPM、NodeJS、nodist、nvm-windows 等等的旧安装。
- 如果你之前使用过这些替代引擎中的一个,那么你很可能在磁盘上某个地方留下了一堆无用的 NPM 包。最好找到它们并删除它们。
一些查找的地方
C:\Program Files\nodejs
C:\Program Files (x86)\nodist
%APPDATA%\npm
%APPDATA%\nvm
"npm install" 阶段报告网络错误——该怎么办?
如果你从自定义 NPM 仓库(例如公司内部的私有服务器或缓存代理)安装包,那么你的项目维护人员会指示你将特殊配置设置添加到你的 .npmrc 文件中。如果这些设置不正确,"npm install" 可能会报告令人困惑的错误,这些错误似乎表明网络故障。重要的是要了解,NPM 工具会在多个位置查找 ".npmrc" 文件(并忽略其他位置)。
没有 Rush,NPM 会在这两个地方查找 "**。npmrc**",并合并它们的内容
- 与你的 package.json 相同的文件夹中(用于在 Git 中存储项目特定的设置)
- 在你的用户主目录中(你的身份验证令牌放在这里)
当 Rush 调用 "npm install" 时,它会在以下两个地方查找 "**。npmrc**"
- "**./common/config/rush/.npmrc**"(在安装期间会被复制到 "**./common/temp/.npmrc**")
- 在你的用户主目录中
为什么 Rush 的 JSON 配置文件中包含 //
注释,而 GitHub 会将它们显示为红色?
JSON 最初被设计为一种机器交换格式,因此它没有正式支持代码注释。最近 JSON 作为一种人为编辑的配置文件格式越来越受欢迎,这显然需要注释。因此,大多数严肃的 JSON 库都能轻松处理注释。(一个明显的例外是 JSON.parse()
;不要使用它——它无法验证模式,并且错误报告很差。)
VS Code 默认情况下会将 JSON 注释突出显示为错误,但它提供了一种可选的 "带注释的 JSON" 模式。要启用此模式,请在 VS Code 中的 **settings.json** 文件中添加以下行
"files.associations": { "*.json": "jsonc" }
GitHub 默认情况下也会将注释突出显示为错误。要解决这个问题,可以将以下行添加到你的 **.gitattributes** 文件中(你可能还需要对受影响的文件进行更改以解决 GitHub 缓存问题)
*.json linguist-language=JSON-with-Comments
有关其他一些可能性的讨论,请参见 问题 #1088。
如何清理 Rush 的安装以避免干扰其他工具?
通常建议使用 Rush 来管理所有单一仓库。Rush 在项目 `node_modules` 文件夹下创建的符号链接可能会使其他工具(例如 NPM 或 Yarn)感到困惑,导致它们出现故障,因为它们期望不同的安装模型。但是,有时这是不可避免的。例如,当将现有仓库迁移到使用 Rush 时,CI 系统可能需要重用现有的工作文件夹来构建使用不同安装模型的不同分支。为了防止干扰,您的 CI 任务首先需要调用一个命令来删除先前安装模型中的旧文件。
对于 Yarn 或 NPM,类似 `git clean -dfx` 的命令通常就足够了。(这会删除文件——在调用之前请 阅读手册!)
对于清理 Rush 安装,不建议使用 `git clean`,因为它无法可靠地处理符号链接。请改用 rush purge 命令来删除 Rush 创建的 `node_modules` 文件夹。