Gatsby 开源贡献实战指南Monorepo 本地开发环境搭建、测试体系与调试流程【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsbyGatsby 采用 Lerna Yarn workspaces 的 monorepo 架构管理其数十个核心包本文基于仓库官方贡献文档 docs/contributing/code-contributions.md完整覆盖从 Node/Yarn 环境准备、fork/clone/yarn run bootstrap初始化、yarn run watch增量编译到gatsby-dev-cli将本地修改同步到测试站点、Jest 单测与 e2e 测试、React 多版本兼容性验证的完整贡献链路并结合package.json、lerna.json、jest.config.js等源码文件解读每个命令背后的实际实现。一、仓库的 Monorepo 结构与工具链基础Gatsby 官方文档明确说明项目使用 monorepo 模式管理众多依赖并依赖Lerna和Yarn来配置仓库同时服务于核心开发active development和文档基础设施变更。选择 Yarn 而非 npm 的核心原因是 Yarn 的workspaces特性——它允许从多个子目录下的package.json统一安装依赖实现更快、更轻量的安装过程。这一点可以从仓库根目录的 package.json 中得到印证{ packageManager: yarn1.22.19, engines: { yarn: ^1.17.3, node: 18.0.0 26, npm: 8.0.0 }, workspaces: [ packages/* ] }几个关键事实Yarn 版本锁定packageManager字段声明仓库使用yarn1.22.19engines要求 Yarn^1系列。因此贡献者必须安装 Yarn 1.x执行yarn --version确认Gatsby monorepo 目前不支持 Yarn 2 及更高版本。Node 版本engines要求18.0.0 26对应文档中说明的支持版本为18、20、22 或 24执行node --version确认即可。workspaces 范围只有packages/*被纳入 workspace共 90 个包starters/、examples/、e2e-tests/等目录是独立站点各自维护自己的package.json。Lerna 侧的配置见 lerna.json{ packages: [packages/*], version: independent, npmClient: yarn, useWorkspaces: true, command: { publish: { allowBranch: release/*, bump: patch, conventionalCommits: true } } }useWorkspaces: true让 Lerna 直接复用 Yarn workspaces 的安装结果version: independent表示各包独立打版本号例如gatsby-dev-cli的package.json中版本为5.17.0-next.0conventionalCommits则决定了发布基于规范化提交信息自动推导版本。ignoreChanges中还列出了**/__tests__/**、**/__mocks__/**等目录——意味着修改测试文件不会触发版本变更这对贡献者编写测试时避免误改版本号很有参考价值。二、搭建本地开发环境2.1 安装 Node 和 Yarn执行node --version确认处于受支持的 Node 版本18、20、22 或 24。安装 Yarn 包管理器并执行yarn --version确认版本为 1.x^1。仓库engines字段要求 Yarn^1.17.3与packageManager声明的 1.22.19 一致。2.2 Fork、clone、bootstrap 与 watchFork 官方gatsbyjs/gatsby仓库后clone 你的 forkgit clone https://github.com/your-username/gatsby.git在仓库根目录执行初始化安装yarn run bootstrap创建主题分支开始开发git checkout -b topics/new-feature-name在仓库根目录运行 watch 命令监听各包源码变更并即时编译yarn run watch源码级解读bootstrap与watch的实际定义在根 package.json 的scripts中prebootstrap: yarn npm run check-versions cross-env COMPILER_OPTIONS\GATSBY_MAJOR5\ lerna run prepare --scope gatsby-core-utils, bootstrap: cross-env COMPILER_OPTIONS\GATSBY_MAJOR5\ npm-run-all -s \lerna-prepare -- --{}\ --, lerna-prepare: lerna run prepare --ignore gatsby-core-utils, watch: lerna run watch --no-sort --stream --concurrency 999可以看出bootstrap的完整链路是prebootstrap先执行一次yarn安装全部 workspace 依赖→npm run check-versions→ 单独编译gatsby-core-utils然后bootstrap通过 Lerna 对所有包运行prepare生产模式构建。而 scripts/check-versions.js 会基于 Lerna 的PackageGraph构建包依赖图用semver.satisfies检查每个包对其他 monorepo 内包的版本声明是否过时例如 A 包声明依赖gatsby-core-utils^5.0.0但实际版本是 5.17.0发现不一致即输出警告并以退出码 1 失败支持--fix自动修正、--allow-next在 alpha/beta 发布时放行next版本。watch命令则通过lerna run watch --no-sort --stream --concurrency 999并发监听所有包。由于全量 watch 资源开销较大Lerna 的run子命令天然支持--scope过滤文档推荐的做法是# 只监听指定包 yarn run watch --scope{gatsby,gatsby-cli} # 只监听 gatsby 一个包 yarn run watch --scopegatsby以 packages/gatsby/package.json 为例其watch脚本为watch: rimraf dist mkdir dist npm run build:internal-plugins npm run build:rawfiles npm-run-all --npm-path npm -p watch:src watch:page-ssr-lambda即先清空并重建dist/再并行监听src源码与 page-SSR lambda 的构建——yarn run watch触发的正是这类各包自定义的watch脚本。提示clone 时可选用git clone --depth1 https://github.com/your-username/gatsby.git做浅克隆以减小下载体积但引用较旧的上游分支时可能出现问题需按需求权衡。2.3 在示例项目中验证修改gatsby-dev-cli修改 Gatsby 核心后需要把改动注入到真实的 Gatsby 站点中验证。仓库提供了 packages/gatsby-dev-cli 专用工具其自述为 CLI helpers for contributors working on Gatsby作用是将你本地构建的各 Gatsby 包文件拷贝进测试站点的node_modules并持续监听变更增量同步。完整操作步骤确认已安装 Gatsby Dev CLIgatsby-dev -v未安装则全局安装yarn global add gatsby-dev-cli将其指向你的 fork 仓库通常只需配置一次gatsby-dev --set-path-to-repo /path/to/my/forked/version/gatsby在每个要测试的站点目录中执行yarn install。在每个测试站点目录内运行gatsby-dev它会把你 clone 的 Gatsby 中已构建的文件拷贝进站点并持续监听 Gatsby 包的变更。只想拷贝单个包如gatsby时gatsby-dev --packages gatsby。注意如果你要修改的包是直接从gatsby主包导出的即站点侧没有显式声明你需要手动将其加入测试站点的package.json例如yarn add gatsby-link或显式指定gatsby-dev --packages gatsby-link。撤销同步、恢复线上版本删除node_modules并还原package.json与 lockfile 后重装或快捷执行git checkout package.json; yarn --force源码级解读从 packages/gatsby-dev-cli/src/index.js 的 CLI 定义可以看到完整的命令面选项说明-p, --set-path-to-repo path设置 Gatsby fork 仓库路径写入 configstore仅需配置一次--packages names...跳过自动扫描显式指定要拷贝的包列表-s, --scan-once只做一次扫描拷贝后退出用于自动化测试/构建场景Gatsby 的 CI 即使用此模式-q, --quiet配合--scan-once时不输出拷贝文件信息-C, --copy-all拷贝packages/下所有模块而非仅gatsby前缀包--force-install禁用向node_modules拷贝文件强制走本地 npm registry依赖其依赖的 verdaccio 私有 registry见 packages/gatsby-dev-cli/src/local-npm-registry--package-manager选择yarn默认或pnpm执行依赖安装-v, --version打印当前安装的 Gatsby Dev CLI 版本工作流上gatsby-dev与yarn run watch是配合使用的后者在 monorepo 内持续把src/编译到dist/前者监听dist/变化并拷贝到测试站点形成改源码 → 自动编译 → 自动同步的闭环。三、添加测试单测、集成测试与 e2e文档给出的测试策略是分层的单元测试优先先用 Jest 添加单元测试。真实场景验证如需在更接近真实应用的环境中验证功能可考虑添加 集成测试 或 端到端测试——两个目录在仓库中均有大量现存用例可参考如 e2e-tests/production-runtime、integration-tests/gatsby-pipeline。全量回归完成后确认所有单元测试通过yarn test源码级解读根package.json中test: npm-run-all --npm-path npm -s lint jest test:peril即一次执行 lint、Jest 单测与 peril 规则测试三部分。Jest 的 monorepo 适配逻辑在 jest.config.js 中roots: pkgs—— 以packages/*各目录为测试根testPathIgnorePatterns排除examples/、deprecated-packages/、各包dist/与__tests__/fixturestransformIgnorePatterns显式放行一批 ESM-only 依赖unified、remark-*、mdast-*等以便转换moduleNameMapper将reach/router映射到 fork 版gatsbyjs/reach-router等关键别名。单包/单文件粒度的运行方式对定位失败用例很有用# 运行单个包的测试 yarn jest package-name # 运行单个测试文件 yarn jest file-path推送代码到 GitHub 后CI 会在受控环境Linux/Windows 等不同机型重跑测试可能暴露本地未发现的失败。本地运行 e2e 测试的三步流程如果你新增了 e2e 测试并希望针对本地修改运行文档给出三步在 monorepo 根目录构建含改动的包yarn lerna run build --scopepackage-name在具体 e2e 测试目录内运行gatsby-dev例如cd e2e-tests/themes/development-runtime gatsby-dev在上一步保持运行的同时新开终端在同一个e2e 测试目录执行yarn test。以 e2e-tests/production-runtime/package.json 为例可看到其test: npm run build npm run start-server-and-test npm run test-env-vars的典型形态先执行真实gatsby build起服务后用 Cypress/Playwright 跑浏览器端断言——这就是gatsby-dev拷贝本地构建产物后所驱动的对象。四、使用 upgrade-react 脚本做多版本 React 兼容性测试仓库提供了 scripts/upgrade-react.js用于更新某个 e2e/integration 测试目录中的 React 版本再运行该目录的测试REACT_VERSION19.0.0 TEST_PATHe2e-tests/production-runtime node ./scripts/upgrade-react.js cd e2e-tests/production-runtime yarn test该脚本会改写测试目录package.json中指定的 React 版本适用于验证 React 19 兼容性、回归旧版 React 的向后兼容、确认功能在跨 React 大版本边界时正常工作。同样的方法适用于任何 e2e 测试目录且 CI 会自动对 React 18 与 React 19 双版本跑 e2e 以捕获兼容性问题。源码级解读脚本本体仅 29 行逻辑清晰——读取${TEST_PATH}/package.json对dependencies与devDependencies两组中的react和react-dom字段做版本替换仅替换已存在的字段写回文件。值得注意的是文件头部注释说明它intentionally does not use in-repo packages because it is ran before we do an install即该脚本在 CI 中于安装依赖之前运行因此不能依赖node_modules里的任何 monorepo 包只能使用 Node 原生 API。这也解释了为什么它通过两个环境变量REACT_VERSION与TEST_PATH而非命令行参数接收输入。五、故障排查Troubleshooting文档列出的三个高频问题与处理方式fork 落后如果你之前已做过初始配置、现在要贡献新改动先 同步你的 fork 与主仓库主分支的最新变更。不同步常导致文件被重命名/移动/删除后找不到文件的错误。重新 bootstrap同步 fork 后重新执行yarn run bootstrap编译所有包——当文件或测试依赖构建产物各包/dist目录时不重新构建会直接失败。保持 watch 运行确保对你正在修改的包保持yarn run watch运行状态。遇到具体问题可以在官方仓库的 Discussions 求助区发起讨论。构建过程的调试可参考仓库的调试文档 docs/docs/debugging.md。六、其他贡献方式与 PR 流程创建自己的插件如果你开发了 loader 或插件官方鼓励开源并发布到 npm。相关文档见 pluginsAPI 规范类内容在 docs/docs/reference 下按参考文档组织。贡献示例站点Gatsby 的政策是仓库中 Using 类示例站点examples 目录仅保留核心团队维护的插件对应的站点——因为其他站点难以保持更新。若要贡献示例站点建议自建 GitHub 仓库并从你的 source 插件等位置链接过去。提交 PR完成全部修改并补齐测试后按 How to open a pull request 的说明提交 PR文档类贡献则参考 docs contributions。七、小结Gatsby 的贡献工作流可以概括为一条主线Yarn 1.x Node 18/20/22/24 → git clone fork → yarn run bootstrapLerna 全量 prepare 构建 → yarn run watch --scope...增量编译 → gatsby-dev / gatsby-dev --packages ...同步到测试站点 → yarn test / yarn jest scopeJest 单测 lint peril → e2e 目录lerna run build → gatsby-dev → yarn test → scripts/upgrade-react.jsReact 多版本兼容验证 → 同步 fork → 提交 PR掌握这条链路后任何针对packages/下核心包的修改都能在本地完成编译 → 同步 → 测试 → 多版本验证的完整闭环这也是仓库 docs/contributing/code-contributions.md 所定义的贡献者标准工作路径。【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Gatsby 开源贡献实战指南：Monorepo 本地开发环境搭建、测试体系与调试流程
Gatsby 开源贡献实战指南Monorepo 本地开发环境搭建、测试体系与调试流程【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsbyGatsby 采用 Lerna Yarn workspaces 的 monorepo 架构管理其数十个核心包本文基于仓库官方贡献文档 docs/contributing/code-contributions.md完整覆盖从 Node/Yarn 环境准备、fork/clone/yarn run bootstrap初始化、yarn run watch增量编译到gatsby-dev-cli将本地修改同步到测试站点、Jest 单测与 e2e 测试、React 多版本兼容性验证的完整贡献链路并结合package.json、lerna.json、jest.config.js等源码文件解读每个命令背后的实际实现。一、仓库的 Monorepo 结构与工具链基础Gatsby 官方文档明确说明项目使用 monorepo 模式管理众多依赖并依赖Lerna和Yarn来配置仓库同时服务于核心开发active development和文档基础设施变更。选择 Yarn 而非 npm 的核心原因是 Yarn 的workspaces特性——它允许从多个子目录下的package.json统一安装依赖实现更快、更轻量的安装过程。这一点可以从仓库根目录的 package.json 中得到印证{ packageManager: yarn1.22.19, engines: { yarn: ^1.17.3, node: 18.0.0 26, npm: 8.0.0 }, workspaces: [ packages/* ] }几个关键事实Yarn 版本锁定packageManager字段声明仓库使用yarn1.22.19engines要求 Yarn^1系列。因此贡献者必须安装 Yarn 1.x执行yarn --version确认Gatsby monorepo 目前不支持 Yarn 2 及更高版本。Node 版本engines要求18.0.0 26对应文档中说明的支持版本为18、20、22 或 24执行node --version确认即可。workspaces 范围只有packages/*被纳入 workspace共 90 个包starters/、examples/、e2e-tests/等目录是独立站点各自维护自己的package.json。Lerna 侧的配置见 lerna.json{ packages: [packages/*], version: independent, npmClient: yarn, useWorkspaces: true, command: { publish: { allowBranch: release/*, bump: patch, conventionalCommits: true } } }useWorkspaces: true让 Lerna 直接复用 Yarn workspaces 的安装结果version: independent表示各包独立打版本号例如gatsby-dev-cli的package.json中版本为5.17.0-next.0conventionalCommits则决定了发布基于规范化提交信息自动推导版本。ignoreChanges中还列出了**/__tests__/**、**/__mocks__/**等目录——意味着修改测试文件不会触发版本变更这对贡献者编写测试时避免误改版本号很有参考价值。二、搭建本地开发环境2.1 安装 Node 和 Yarn执行node --version确认处于受支持的 Node 版本18、20、22 或 24。安装 Yarn 包管理器并执行yarn --version确认版本为 1.x^1。仓库engines字段要求 Yarn^1.17.3与packageManager声明的 1.22.19 一致。2.2 Fork、clone、bootstrap 与 watchFork 官方gatsbyjs/gatsby仓库后clone 你的 forkgit clone https://github.com/your-username/gatsby.git在仓库根目录执行初始化安装yarn run bootstrap创建主题分支开始开发git checkout -b topics/new-feature-name在仓库根目录运行 watch 命令监听各包源码变更并即时编译yarn run watch源码级解读bootstrap与watch的实际定义在根 package.json 的scripts中prebootstrap: yarn npm run check-versions cross-env COMPILER_OPTIONS\GATSBY_MAJOR5\ lerna run prepare --scope gatsby-core-utils, bootstrap: cross-env COMPILER_OPTIONS\GATSBY_MAJOR5\ npm-run-all -s \lerna-prepare -- --{}\ --, lerna-prepare: lerna run prepare --ignore gatsby-core-utils, watch: lerna run watch --no-sort --stream --concurrency 999可以看出bootstrap的完整链路是prebootstrap先执行一次yarn安装全部 workspace 依赖→npm run check-versions→ 单独编译gatsby-core-utils然后bootstrap通过 Lerna 对所有包运行prepare生产模式构建。而 scripts/check-versions.js 会基于 Lerna 的PackageGraph构建包依赖图用semver.satisfies检查每个包对其他 monorepo 内包的版本声明是否过时例如 A 包声明依赖gatsby-core-utils^5.0.0但实际版本是 5.17.0发现不一致即输出警告并以退出码 1 失败支持--fix自动修正、--allow-next在 alpha/beta 发布时放行next版本。watch命令则通过lerna run watch --no-sort --stream --concurrency 999并发监听所有包。由于全量 watch 资源开销较大Lerna 的run子命令天然支持--scope过滤文档推荐的做法是# 只监听指定包 yarn run watch --scope{gatsby,gatsby-cli} # 只监听 gatsby 一个包 yarn run watch --scopegatsby以 packages/gatsby/package.json 为例其watch脚本为watch: rimraf dist mkdir dist npm run build:internal-plugins npm run build:rawfiles npm-run-all --npm-path npm -p watch:src watch:page-ssr-lambda即先清空并重建dist/再并行监听src源码与 page-SSR lambda 的构建——yarn run watch触发的正是这类各包自定义的watch脚本。提示clone 时可选用git clone --depth1 https://github.com/your-username/gatsby.git做浅克隆以减小下载体积但引用较旧的上游分支时可能出现问题需按需求权衡。2.3 在示例项目中验证修改gatsby-dev-cli修改 Gatsby 核心后需要把改动注入到真实的 Gatsby 站点中验证。仓库提供了 packages/gatsby-dev-cli 专用工具其自述为 CLI helpers for contributors working on Gatsby作用是将你本地构建的各 Gatsby 包文件拷贝进测试站点的node_modules并持续监听变更增量同步。完整操作步骤确认已安装 Gatsby Dev CLIgatsby-dev -v未安装则全局安装yarn global add gatsby-dev-cli将其指向你的 fork 仓库通常只需配置一次gatsby-dev --set-path-to-repo /path/to/my/forked/version/gatsby在每个要测试的站点目录中执行yarn install。在每个测试站点目录内运行gatsby-dev它会把你 clone 的 Gatsby 中已构建的文件拷贝进站点并持续监听 Gatsby 包的变更。只想拷贝单个包如gatsby时gatsby-dev --packages gatsby。注意如果你要修改的包是直接从gatsby主包导出的即站点侧没有显式声明你需要手动将其加入测试站点的package.json例如yarn add gatsby-link或显式指定gatsby-dev --packages gatsby-link。撤销同步、恢复线上版本删除node_modules并还原package.json与 lockfile 后重装或快捷执行git checkout package.json; yarn --force源码级解读从 packages/gatsby-dev-cli/src/index.js 的 CLI 定义可以看到完整的命令面选项说明-p, --set-path-to-repo path设置 Gatsby fork 仓库路径写入 configstore仅需配置一次--packages names...跳过自动扫描显式指定要拷贝的包列表-s, --scan-once只做一次扫描拷贝后退出用于自动化测试/构建场景Gatsby 的 CI 即使用此模式-q, --quiet配合--scan-once时不输出拷贝文件信息-C, --copy-all拷贝packages/下所有模块而非仅gatsby前缀包--force-install禁用向node_modules拷贝文件强制走本地 npm registry依赖其依赖的 verdaccio 私有 registry见 packages/gatsby-dev-cli/src/local-npm-registry--package-manager选择yarn默认或pnpm执行依赖安装-v, --version打印当前安装的 Gatsby Dev CLI 版本工作流上gatsby-dev与yarn run watch是配合使用的后者在 monorepo 内持续把src/编译到dist/前者监听dist/变化并拷贝到测试站点形成改源码 → 自动编译 → 自动同步的闭环。三、添加测试单测、集成测试与 e2e文档给出的测试策略是分层的单元测试优先先用 Jest 添加单元测试。真实场景验证如需在更接近真实应用的环境中验证功能可考虑添加 集成测试 或 端到端测试——两个目录在仓库中均有大量现存用例可参考如 e2e-tests/production-runtime、integration-tests/gatsby-pipeline。全量回归完成后确认所有单元测试通过yarn test源码级解读根package.json中test: npm-run-all --npm-path npm -s lint jest test:peril即一次执行 lint、Jest 单测与 peril 规则测试三部分。Jest 的 monorepo 适配逻辑在 jest.config.js 中roots: pkgs—— 以packages/*各目录为测试根testPathIgnorePatterns排除examples/、deprecated-packages/、各包dist/与__tests__/fixturestransformIgnorePatterns显式放行一批 ESM-only 依赖unified、remark-*、mdast-*等以便转换moduleNameMapper将reach/router映射到 fork 版gatsbyjs/reach-router等关键别名。单包/单文件粒度的运行方式对定位失败用例很有用# 运行单个包的测试 yarn jest package-name # 运行单个测试文件 yarn jest file-path推送代码到 GitHub 后CI 会在受控环境Linux/Windows 等不同机型重跑测试可能暴露本地未发现的失败。本地运行 e2e 测试的三步流程如果你新增了 e2e 测试并希望针对本地修改运行文档给出三步在 monorepo 根目录构建含改动的包yarn lerna run build --scopepackage-name在具体 e2e 测试目录内运行gatsby-dev例如cd e2e-tests/themes/development-runtime gatsby-dev在上一步保持运行的同时新开终端在同一个e2e 测试目录执行yarn test。以 e2e-tests/production-runtime/package.json 为例可看到其test: npm run build npm run start-server-and-test npm run test-env-vars的典型形态先执行真实gatsby build起服务后用 Cypress/Playwright 跑浏览器端断言——这就是gatsby-dev拷贝本地构建产物后所驱动的对象。四、使用 upgrade-react 脚本做多版本 React 兼容性测试仓库提供了 scripts/upgrade-react.js用于更新某个 e2e/integration 测试目录中的 React 版本再运行该目录的测试REACT_VERSION19.0.0 TEST_PATHe2e-tests/production-runtime node ./scripts/upgrade-react.js cd e2e-tests/production-runtime yarn test该脚本会改写测试目录package.json中指定的 React 版本适用于验证 React 19 兼容性、回归旧版 React 的向后兼容、确认功能在跨 React 大版本边界时正常工作。同样的方法适用于任何 e2e 测试目录且 CI 会自动对 React 18 与 React 19 双版本跑 e2e 以捕获兼容性问题。源码级解读脚本本体仅 29 行逻辑清晰——读取${TEST_PATH}/package.json对dependencies与devDependencies两组中的react和react-dom字段做版本替换仅替换已存在的字段写回文件。值得注意的是文件头部注释说明它intentionally does not use in-repo packages because it is ran before we do an install即该脚本在 CI 中于安装依赖之前运行因此不能依赖node_modules里的任何 monorepo 包只能使用 Node 原生 API。这也解释了为什么它通过两个环境变量REACT_VERSION与TEST_PATH而非命令行参数接收输入。五、故障排查Troubleshooting文档列出的三个高频问题与处理方式fork 落后如果你之前已做过初始配置、现在要贡献新改动先 同步你的 fork 与主仓库主分支的最新变更。不同步常导致文件被重命名/移动/删除后找不到文件的错误。重新 bootstrap同步 fork 后重新执行yarn run bootstrap编译所有包——当文件或测试依赖构建产物各包/dist目录时不重新构建会直接失败。保持 watch 运行确保对你正在修改的包保持yarn run watch运行状态。遇到具体问题可以在官方仓库的 Discussions 求助区发起讨论。构建过程的调试可参考仓库的调试文档 docs/docs/debugging.md。六、其他贡献方式与 PR 流程创建自己的插件如果你开发了 loader 或插件官方鼓励开源并发布到 npm。相关文档见 pluginsAPI 规范类内容在 docs/docs/reference 下按参考文档组织。贡献示例站点Gatsby 的政策是仓库中 Using 类示例站点examples 目录仅保留核心团队维护的插件对应的站点——因为其他站点难以保持更新。若要贡献示例站点建议自建 GitHub 仓库并从你的 source 插件等位置链接过去。提交 PR完成全部修改并补齐测试后按 How to open a pull request 的说明提交 PR文档类贡献则参考 docs contributions。七、小结Gatsby 的贡献工作流可以概括为一条主线Yarn 1.x Node 18/20/22/24 → git clone fork → yarn run bootstrapLerna 全量 prepare 构建 → yarn run watch --scope...增量编译 → gatsby-dev / gatsby-dev --packages ...同步到测试站点 → yarn test / yarn jest scopeJest 单测 lint peril → e2e 目录lerna run build → gatsby-dev → yarn test → scripts/upgrade-react.jsReact 多版本兼容验证 → 同步 fork → 提交 PR掌握这条链路后任何针对packages/下核心包的修改都能在本地完成编译 → 同步 → 测试 → 多版本验证的完整闭环这也是仓库 docs/contributing/code-contributions.md 所定义的贡献者标准工作路径。【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考