$ rush build -t @monorepo/app1
该命令会执行 app1 以及 app1 依赖的 package 的构建脚本。
类似的，还有 -f(from) 参数，可以使命令只作用于当前 package 以及依赖了该 package 的 package。
保证依赖版本一致性
Monorepo 中的项目应当尽量保证依赖版本的一致性，否则很有可能出现重复打包以及其他的问题。
Rush 则提供了许多能力来保证这一点，如rush check、rush add -p package-name -m 以及 ensureConsistentVersions。
有兴趣的同学可以自行翻阅 Rush 的官方文档，十分详尽，对于一些常见问题也有说明。
Package 引用规范
传统引用方式，构建完成后，app 直接引用 package 的构建产物。开发阶段可以通过构建工具提供的能力保证实时构建（如 tsc --watch）
优点：规范，对 app 友好。
缺点：随着模块增多，package 热更新速度可能变得难以忍受。
package.json 中的 main 字段配置为源文件的入口文件，引用该 package 的 app 需要将该 package 纳入编译流程。
优点：借助 app 的热更新能力，自身没有生成构建产物的过程，热更新速度快
缺点：需要 app 进行适配， alias 适配繁琐；
对于项目内部使用的 packages ，称为 features，不应当向外发布，直接将 main 字段设置为源文件入口并配置 app 项目的 webpack，走后编译形式。
对于需要对外发布的 packages，不应该也不允许引用 features，必须要有构建过程，如果需要使用源码开发增加热更新速度，可以新增一个自定义的入口字段，app 的 webpack 配置中优先识别该入口字段即可。
补充：rush build 命令是支持构建产物缓存的，如果 app 拆分粒度够小，可复用的包足够多，同时打包镜像支持构建产物缓存的 set 与 get，就可以做到增量构建 app。
Workspace protocol (workspace:)
在 PNPM 和 Yarn 支持 Workspace 能力之前，Rush 就诞生了。 Rush 的方法是将所有软件包集中安装在 common / temp 文件夹中，然后 Rush 创建从每个项目到 common / temp 的符号链接。与 PNPM Workspace 本质上是等效的。
开启 PNPM workspace 能力从而可以使用 workspace:协议保证引用版本的确定性，使用了该协议引用的 package 只会使用 Monorepo 中的内容。
"dependencies": {
"foo": "workspace:*",
"bar": "workspace:~",
"qar": "workspace:^",
"zoo": "workspace:^1.5.0"
推荐引用 Monorepo 内的 package 时统一使用该协议，引用本地最新版本内容，保证更改能够及时扩散同步至其他项目，这也是 Monorepo 的优势所在。
若一定要使用远端版本，需要在 rush.json 中配置具体 project （增加 cyclicDependencyProjects 配置），详见 rush_json。
很幸运的是 PNPM workspace 中 workspace:* 可以匹配 prerelease 版本 👉 Local prerelease version of packages should be linked only if the range is *
Monorepo Project Dependencies Duplicate
这个问题类似于前面提到的 Yarn duplicate，但并不是 Yarn 独有的。
假设存在以下依赖关系（将 Yarn duplicate 的例子进行改造，放在 Monorepo 场景中）
app1 以及 package1 同属于 Monorepo 内部 project。
在 Rush(pnpm)/Yarn 项目中，会严格按照 Monorepo 内 project 的 package.json 所声明的版本进行安装，即 app1 安装 lib-a@1.1.0，package1 安装 lib-a@1.2.0。
此时对 app1 进行打包，则 lib-a@1.1.0 和 lib-a@1.2.0 都会被打包。
对这个结果你也许会有一些意外，但仔细想想，又很自然。
换一种方式理解，整个 Monorepo 是一个大的虚拟 project，我们所有的 project 都作为这个虚拟 project 的直接依赖存在。
"name": "fake-project",
"version": "1.0.0",
"dependencies": {
"@fake-project/app1": "1.0.0",
"@fake-project/package1": "1.0.0"
安装依赖时，(p)npm 首先下载直接依赖项，然后再下载间接依赖项，并且在安装到相同模块时，判断已安装的模块版本（直接依赖项）是否符合新模块（间接依赖项）的版本范围，如果符合则跳过，不符合则在当前模块的 node_modules 下安装该模块。
而 app1 和 package1 的直接依赖关系 lib-a 是该 fake-project 的间接依赖项，无法满足上述判断条件，于是按照对应 package.json 中描述的版本安装。
解决方案：Rush: Preferred versions
Rush 可以通过手动指定 preferredVersions 的方式，避免两个可兼容版本的重复。这里将 Monorepo 中 lib-a 的 preferredVersions 指定为 1.2.0，相当于在该虚拟 project 下直接安装了指定的版本的模块，作为直接依赖项。
"name": "fake-project",
"version": "1.0.0",
"dependencies": {
"@fake-project/app1": "1.0.0",
"@fake-project/package1": "1.0.0",
"lib-a": "1.1.0"
对于 Yarn，由于 Yarn duplicate 的存在，就算在根目录指定安装确定版本的 lib-a 也是无效的。
但是依旧有两种方案可以进行处理：
通过 yarn-deduplicate 针对性的修改 yarn.lock；
使用resolutions 字段。过于粗暴，不像 preferredVersions 可以允许不兼容版本的存在，不推荐。
需要谨记：在 Yarn 下消除重复依赖，也应该一个 Package 一个 Package 的去进行处理，小心使得万年船。
对于存在副作用的公共库，版本最好保持统一；
对于其他的体积小（或支持按需加载）、无副作用的公共库，重复打包在一定程度上可以接受的。
prettier
由于根目录不再存在 node_modules，故需要每个项目安装一个 prettier 作为 devDependency 并编写 .prettierrc.js 文件。
本着偷懒的原则，根目录新建 .prettierrc.js（不依赖任何第三方包），全局安装 prettier 解决该问题。
eslint
先看一个场景，若在项目中使用 eslint-config-react-app，除了需要安装 eslint-config-react-app，还需要安装一系列 peerDependencies 插件。
为什么 eslint-config-react-app 不将这一系列插件作为 dependencies 内置，而是作为 peerDependencies？使用者并不需要关心预设配置内引用了哪些插件。
具体讨论可以查看该 issue，里面有相关问题的讨论： Support having plugins as dependencies in shareable config #3458 。
总而言之：和 eslint 插件的具体查找方式有关，如果因为依赖提升失败（多版本冲突），导致需要的插件被装在了非根目录 node_modules 下，就可能产生问题，而用户自行安装 peerDependencies 可以保证不会出现该问题。
当然，我们也发现一些开源的 eslint 预设配置不需要安装 peerDependencies，这些预设利用了 yarn 和 npm 的扁平 node_modules 结构，也就是依赖提升，装的包都被提升至根目录 node_modules，故可以正常运作。即便如此，在基于 Yarn 的 Monorepo 中，依赖一旦复杂起来，就可能出现插件无法被查找到的情况，能够正常运转就像一个有趣的巧合。
在 Rush 中，不存在依赖提升（提升也不一定靠谱），装一系列的插件又过于繁琐，则可以通过打补丁的方式绕过。
git hooks
通常会在项目中使用 husky 注册 pre-commit 和 commit-msg 钩子，用于校验代码风格以及 commit 信息。
很明显，在 Rush 项目的结构下，根目录是没有 node_modules 的，无法直接使用 husky。
我们可以借助 rush init-autoinstaller 的能力来达到一样的效果，本节主要参考官方文档 Installing Git hooks 以及 Enabling Prettier 的内容。
$ rush init-autoinstaller --name rush-lint
$ cd common/autoinstallers/rush-lint
$ pnpm i @commitlint/cli @commitlint/config-conventional @microsoft/rush-lib eslint execa prettier lint-staged
$ rush update-autoinstaller --name rush-lint
在 rush-lint 目录下新增 commit-lint.js 以及 commitlint.config.js，内容如下
commit-lint.js
const path = require('path');
const fs = require('fs');
const execa = require('execa');
const gitPath = path.resolve(__dirname, '../../../.git');
const configPath = path.resolve(__dirname, './commitlint.config.js');
const commitlintBinPath = path.resolve(__dirname, './node_modules/.bin/commitlint');
if (!fs.existsSync(gitPath)) {
console.error('no valid .git path');
process.exit(1);
main();
async function main() {
try {
await execa('bash', [commitlintBinPath, '--config', configPath, '--cwd', path.dirname(gitPath), '--edit'], {
stdio: 'inherit',
} catch (\_e) {
process.exit(1);
commitlint.config.js
const rushLib = require("@microsoft/rush-lib");
const rushConfiguration = rushLib.RushConfiguration.loadFromDefaultLocation();
const packageNames = [];
const packageDirNames = [];
rushConfiguration.projects.forEach((project) => {
packageNames.push(project.packageName);
const temp = project.projectFolder.split("/");
const dirName = temp[temp.length - 1];
packageDirNames.push(dirName);
const allScope = ["all", ...packageDirNames, ...packageNames];
module.exports = {
extends: ["@commitlint/config-conventional"],
rules: {
"scope-enum": [2, "always", allScope],
注意：此处不需要新增 prettierrc.js（根目录已存在） 以及 eslintrc.js（各项目已存在）。
根目录新增 .lintstagedrc 文件
.lintstagedrc
"{apps,packages,features}/**/*.{js,jsx,ts,tsx}": [
"eslint --fix --color",
"prettier --write"
"{apps,packages,features}/**/*.{css,less,md}": ["prettier --write"]
完成了相关依赖的安装以及配置的编写，我们接下来将相关命令执行注册在 rush 中。
修改 common/config/rush/command-line.json 文件中的 commands 字段。
"commands": [
"name": "commitlint",
"commandKind": "global",
"summary": "Used by the commit-msg Git hook. This command invokes commitlint to lint commit message.",
"autoinstallerName": "rush-lint",
"shellCommand": "node common/autoinstallers/rush-lint/commit-lint.js"
"name": "lint",
"commandKind": "global",
"summary": "Used by the pre-commit Git hook. This command invokes eslint to lint staged changes.",
"autoinstallerName": "rush-lint",
"shellCommand": "lint-staged"
最后，将 rush commitlint 以及 rush lint 两个命令分别与 commit-msg 以及 pre-commit钩子进行绑定。
common/git-hooks 目录下增加 commit-msg 以及 pre-commit 脚本。
commit-msg
#!/bin/sh
node common/scripts/install-run-rush.js commitlint || exit $?
pre-commit
#!/bin/sh
node common/scripts/install-run-rush.js lint || exit $?
如此，便完成了需求。
避免全局安装 eslint 以及 prettier
经过上一节的处理，在 rush-lint 目录下安装了 eslint 以及 prettier 后，我们便无需全局安装了，只需要配置一下 VSCode 即可。
"npm.packageManager": "pnpm",
"eslint.packageManager": "pnpm",
"eslint.nodePath": "common/autoinstallers/rush-lint/node_modules/eslint",
"prettier.prettierPath": "common/autoinstallers/rush-lint/node_modules/prettier"
| yarn | rush(x) | detail |
|---|
| yarn install | rush install | 安装依赖 |
| yarn upgrade | rush update | rush update 安装依赖，基于 lock 文件
rush update --full 全量更新到符合 package.json 的最新版本 |
| yarn add package-name | rush add -p package-name | yarn add 默认安装版本号为 ^ 开头，可接受小版本更新
rush add 默认安装版本号为 ~ 开头，仅接受补丁更新
rush add 可通过增加 --caret 参数达到与 yarn add 效果一致
rush add 不可一次性安装多个 package |
| yarn add package-name --dev | rush add -p package-name --dev | - |
| yarn remove package-name | - | rush 不提供 remove 命令 |
| - | rush build | 执行文件存在变更（基于 git）的项目的 build 脚本
rush build -t @monorepo/app1 表示只构建 @monorepo/app1 及其依赖的 package
rush build -T @monorepo/app1 表示只构建 @monorepo/app1 依赖的 package，不包含其本身 |
| - | rush rebuild | 默认执行所有项目的 build 脚本 |
| yarn xxx(自定义脚本) | rushx xxx(自定义脚本) | yarn xxx 执行当前目录下 package.json 中的 xxx 脚本(npm scripts)
rushx xxx 同理。可以直接执行 rushx 查看当前项目所支持的脚本命令。 |
$ git pull
$ rush update
$ rush rebuild -T @monorepo/app1
$ cd ./apps/app1
$ rushx start
Rush.js
node_modules 困境
Why should we use pnpm?
平铺 node_modules 不是唯一的路
