编写补丁
这些说明涵盖了为 React Strict DOM 仓库做出贡献的过程。 您将学习如何在本地运行任务和测试，以及如何提交和更新补丁。
如果您计划开发新功能或进行重大更改，请在开始工作之前打开一个讨论，提出详细的建议。 我们不希望您浪费精力在可能不被接受的 pull request 上。
贡献者许可协议 ("CLA")
为了接受您的 pull request，我们需要您完成并提交 CLA。 您只需执行一次此操作即可处理 Meta 的任何开源项目。
通过贡献 React Strict DOM，您同意您的贡献将根据仓库根目录中的 LICENSE 文件获得许可。
创建一个新分支
使用来自上游的最新更改更新本地 main 结帐。 <remote> 应该是 origin 或 upstream，具体取决于您是从 fork 还是源仓库工作。
git checkout main
git pull <remote> main
安装依赖
npm i
创建一个新分支，通常从 main 开始
git checkout -b <branch-name>
文档
可以对包进行的文档更改可以在 apps 目录中的 website 包中找到。 要在本地运行文档网站
npm run dev -w website
开发任务
大多数贡献通常是对 packages 目录中的 react-strict-dom 包进行的。 每次提交时，linter 和代码格式化任务将自动执行（尽可能自动修复）。
在开发过程中，最好在单独的终端中运行和监视单元测试
npm run jest -- --watch
可以按如下方式运行 Flow 类型检查
npm run flow
可以按如下方式运行所有测试
npm test
如果您需要更新其中一个已修补的 node_modules，请直接在 node_modules 中编辑该文件，然后运行
npx patch-package <package-name>
集成测试
还可以针对使用 Expo 构建的示例 Web 和原生应用程序对每个补丁进行可视化测试。 此软件包可以在 apps 目录中的 examples 软件包中找到。
首先，在更改时构建并自动重建 react-strict-dom
npm run dev -w react-strict-dom
在另一个进程中，启动示例应用程序
npm run dev -w examples
要在浏览器或本地模拟器中加载应用程序，请按照终端中的 Expo 说明进行操作。 您可能需要安装 XCode 和 Android Studio 才能使用模拟器。
要打开原生应用程序的 React DevTools，请在运行 Expo 的终端中按 Shift + M，然后选择“Open React devtools”。
要在设备上进行测试，请按照这些说明在设备上安装 Expo Go。 使用 Expo Go 扫描 QR 码以在手机上加载示例应用程序。
性能测试
如果对可能影响性能的本机代码路径进行了更改，则值得在本地运行性能基准测试，以便尽早了解补丁导致的任何改进或回归（CI 始终运行这些测试）。 有可用的 perf 和 size 基准。 此软件包可以在 packages 目录中的 benchmarks 软件包中找到。
npm run perf -w benchmarks
npm run size -w benchmarks
要将补丁的结果与基本分支进行比较，请首先从 main 运行这些任务，然后再从补丁运行这些任务。 可以通过运行以下任务并提供前后文件的路径来生成比较数据。
npm run compare -w benchmarks -- <path-to-base.json> <path-to-patch.json>
准备合并请求
在审查之前，应清理分支。 可以使用交互式 rebase 来压缩提交、重新排序提交和重写提交。 例如，这将对分支上 HEAD 的最后 5 次提交运行交互式 rebase。
git rebase -i HEAD^5
准备好要审查的分支后，应将其推送到 GitHub
git push <remote> <branch>
针对 React Strict DOM 仓库创建一个“Pull Request”。
更新合并请求
要使用 origin 的 main 的最新更改更新分支
git checkout main
git pull <remote> main
git checkout <branch-name>
git rebase main
这会将分支 rebase 到 main 上，并提示解决任何潜在冲突。 每次更新后重新安装依赖项。
如果在提交审核后对分支进行了更改，则可以再次 rebase 该分支（例如，使用修复程序更新提交），然后需要将其强制推送到 GitHub。
git push -f <remote> <branch>
代码审查
机器人可能会在您的合并请求中评论并提出建议。 通常，我们要求您先解决这些问题，然后维护人员才会审查您的代码。 首先审查您自己的代码也是一个好主意，并在适当的地方为审查人员提供上下文注释。
如果请求并解决了更改，请请求审查以通知审查人员再次查看。 一旦“代码所有者”批准了合并请求，就可以合并它。