前端GraphQL【免费下载链接】apollo-clientThe industry-leading GraphQL client for TypeScript, JavaScript, React, Vue, Angular, and more. Apollo Client delivers powerful caching, intuitive APIs, and comprehensive developer tools to accelerate your app development.项目地址https://gitcode.com/gh_mirrors/ap/apollo-client点击查看免费下载Apollo Client 是 Apollo GraphQL 生态中最核心的开源项目之一它以 npm workspace 单仓库monorepo的形式维护主包、codegen 与 codemods 等多个工作区。本篇指南基于仓库根目录的 CONTRIBUTING.md 展开系统讲解社区贡献者从报告 Issue、提交 PR、编写 changeset到本地构建、测试、联调真实应用的完整路径并结合当前仓库的源码与配置文件给出可验证的实操细节。读完本文你将掌握 Apollo Client 的贡献流程、开发命令体系与 AI 辅助编程时代下的协作规范能够以符合项目要求的方式提交第一个高质量 PR。参与方式总览由易到难的六条路径Apollo Client 欢迎任何经验水平的开发者参与官方将贡献方式按难度从低到高排列如下报告 bug填写规范化的 Issue附上可复现的最小案例改进文档修正错别字、补充示例或重写文档段落响应他人 Issue帮助社区成员定位问题、给出绕行方案编写 changeset为版本管理与 changelog 生成提供素材提交小型 bug 修复改动小于 20 行代码并附带测试建议新特性在特性请求仓库中提出设计讨论。此外还有大 PR路径大 bug 修复与新特性以及面向 AI 辅助编程的专门规范下文逐一展开。Issues高质量贡献的起点报告 bug三个必备要素要最大化问题被快速修复的概率bug 报告需要包含以下三项内容预期结果Intended outcome描述 bug 发生时你试图完成的目标并附上尽可能多的相关代码实际结果Actual outcome描述实际发生了什么包括相关错误信息、日志的截图或复制粘贴文本可重点查看浏览器控制台、服务端控制台与网络日志。请避免使用不工作坏了这类模糊表述复现步骤How to reproduce给出维护者或贡献者可以照做的复现指引越具体越好只提及复现 bug 所必需的信息并避免对根因的臆测。一个关键建议是用最小复现来隔离问题。在很多情况下构建最小复现的过程本身就会揭示 bug 的真正来源其实在库之外从而为所有人节省时间。改进文档与响应 Issue文档、示例与开源内容的改进是上手门槛最低的贡献方式。任何细微的改进都可以直接开 PR如果希望做大改或重写建议先在特性请求仓库中开一个 feature request 进行讨论再动手写 PR。响应他人 Issue 同样是重要贡献帮助分析问题、识别根因或提供 workaround。如果你希望在此过程中承担更积极的角色可以直接回复 Issue 并参与讨论。Changesets版本与发布的核心机制Apollo Client 使用 changesets 自动化版本管理和发布流程。任何包含代码改动的 PR 都必须附带一个 changeset本地在分支上运行npx changesetchangeset CLI 会引导你完成两步输入对应的 semver 版本提升类型major / minor / patch以及描述本次改动。你可以直接在命令行输入简短描述然后在.changeset目录下编辑生成的 Markdown 文件。编辑时可以使用 GitHub Flavored Markdown 的全部特性如列表、代码块、链接。需要注意你在 changeset 中填写的描述将被用于生成未来版本的CHANGELOG.md条目与发布说明因此描述越完整、越准确越好。从仓库配置看.changeset/config.json 声明了发布的基础行为changelog 使用changesets/changelog-github生成器并关联apollographql/apollo-client仓库access为public公开发布baseBranch为maincommit为false。发布流水线由 package.json 中的脚本驱动changeset-version应用 changeset 并更新依赖与changeset-publish构建后执行changeset publishCI 侧还有changeset-check用于检查是否遗漏 changeset。小型 bug 修复快车道对于改动少于 20 行代码的小型 bug 修复可以直接开 PR。维护者会尽快合并理想情况下当天发布新版本。唯一硬性要求是必须附带一个能够验证你所修复 bug 的测试。这与仓库的代码审查准则相呼应——测试是合并的门槛。建议新特性Apollo Client 的大多数特性都源自社区建议。特性建议与讨论类 Issue 已不再由当前仓库的 issue tracker 管理需要在特性请求仓库中新建 feature request / discussion本仓库中打开的这类 Issue 会被关闭。大 PR先设计共识再写代码大 PR 包括大型 bug 修复与新特性。这类改动风险高、未必总能合并因此项目要求先在设计上达成共识以减少可能的返工。完整流程共七步开 Issuebug 在当前仓库开feature request 在特性请求仓库开达成共识部分贡献者与社区成员应一致认为该 bug/特性重要且值得投入实现约定预期行为在 Issue 中明确修复到什么程度算修复新特性的开发者使用体验是什么样约定实现计划写出实现方案——需要新增或重写哪些模块一个 PR 还是多个增量 PR谁负责哪部分提交 PR如果改动依赖多个补丁请一次只提交一个否则在第一个被 review 和合并期间其他补丁可能过期。要避免顺手改式的无关变更——与本次改进无关的内容尤其是无关代码的格式调整应放入独立 PRReview至少一位核心贡献者签字认可后才能合并。提交前请先自我 review 一遍代码可以加速合并合并并发布。代码审查指南六条核心标准每一行进入 Apollo 包的代码都必须由至少一位熟悉该代码库的核心贡献者审查。审查重点关注CI 检查必须通过这是 review 的先决条件由 PR 作者负责测试不过PR 不会被 review简洁性Simplicity是否用最简单的方式达成目标文件过多、函数冗余、代码行过于复杂时应提出更简单方案。尤其要避免在简单、小巧、务实的修复足以解决问题时去实现一个过度通用的方案测试Testing测试能否保证代码在周边变化时不回归回归时新增测试能否帮助定位库的哪个部分出了问题是否覆盖了合适的边界情况新代码的所有重要代码路径是否至少被执行一次当前仓库的测试体量提供了天然参照——src下几乎每个模块都配对了__tests__目录例如 src/core/ApolloClient.ts 对应 src/core/tests测试矩阵横跨 React 17/18/19、GraphQL 16/17 与 RxJS 最小版本无冗余或无关改动PR 不应携带随机格式改动重构应尽量与 bug 修复或特性拆分到不同 PR恰当的注释代码应被注释或以清晰的自文档化方式编写符合语言惯例TypeScript 中要确保类型具体且正确ES2015 中优先使用 import 而非 require、使用 const 而非 var。项目还配置了严格的 ESLint 规则EXTENDED_RULES1 eslint --max-warnings 0与 Prettier 格式检查从工具层面强制多数惯例。本地开发环境构建与测试构建 Apollo Client一次性构建整个项目npm run build该命令由 package.json 的prebuild清理产物与build串联node config/build.ts会按序执行 config/build.ts 中定义的多步流水线包括prepareDist准备产物目录、addExports按package.json的 exports 生成入口、typescript调用tsc编译详见 config/compileTs.ts、babelTransformBabel 转换、updateVersion写入版本号、inlineInheritDoc、deprecateInternals内部 API 弃用标记、processInvariants处理 invariant 错误码与verifySourceMaps校验 source map等。构建产物输出到dist目录同时产出 ESM 与 CommonJS.cjs两种格式。如果是 monorepo 中的特定工作区CLAUDE.md 给出了示例npm run build -w codegen只构建 codegen 工作区见 codegen/package.json。运行测试一次性运行全部测试npm run test实际上npm test会以--expose-gc等 Node 参数启动 Jest并指向统一的 Jest 配置 config/jest.config.ts。监听模式运行全部测试npm run test:watch只运行指定测试直接调用 jest传入 jest 配置并用testRegex选项筛选jest --config ./config/jest.config.ts --testRegex __tests__/useQuery.test.tsx从 config/jest.config.ts 可以看到测试被组织为六个 Jest 项目并行运行Core Tests纯 TypeScript 核心逻辑测试ts-jest 转译不做类型检查类型检查由 CI 中的tsc完成Core Tests - RxJS min version用最小支持的 RxJS 版本rxjs-min即 7.3.0验证核心兼容性Core Tests - GraphQL 16将graphql映射到graphql-16包验证 GraphQL 16 兼容性ReactDOM 17 / 18 / 19三个 React 版本的项目通过moduleNameMapper将react、react-dom分别映射到react-17、react-18等别名其中 React 17 项目会忽略 Suspense 相关测试Suspense 仅支持 React 18。配套的npm run test:coverage含 lcov 覆盖率报告、npm run test:memory内存测试见 scripts/memory与npm run test:codegencodegen 集成测试覆盖了更深入的验证场景。代码质量与静态检查仓库在 CLAUDE.md 中归纳了完整的质量门禁命令合并前通常需要在本地跑通npm run typecheckTypeScript 类型检查含 integration-tests 的类型测试npm run lintESLint 严格规则检查--max-warnings 0npm run format/npm run check:formatPrettier 格式化与校验npm run knip检测未使用的文件与导出npm run madge检测循环依赖npm run bundlesize构建后校验包体积预算。这些检查与 CI 中的必过项共同构成了代码审查指南中Required CI checks pass的具体含义。将本地 checkout 链接到真实应用有时需要在真实应用中验证 Apollo Client 开发分支的改动效果。官方推荐的链路是以 Apollo fullstack 教程应用为宿主用符号链接把 checkout 接入应用。以下为完整步骤[apollo-client-root]代表 Apollo Client checkout 的根目录[fullstack-tutorial-root]代表教程应用的根目录。1. 克隆并安装 Apollo Clientgit clone apollo-client 仓库地址 cd apollo-client npm i cd ..2. 克隆并安装 fullstack tutorial服务端与客户端各自安装依赖git clone fullstack-tutorial 仓库地址 cd fullstack-tutorial cd final/server npm i cd ../client npm i3. 将应用的apollo/client指向 checkout 的编译产物# 假设仍位于 [fullstack-tutorial-root]/final/client cd node_modules/apollo rm -Rf ./client ln -s [apollo-client-root]/dist client这里的dist正是npm run build的输出目录对应 package.json 中main与module字段指向的位置。4. 若使用 React避免重复 React 版本导致的 hook 错误让应用复用 checkout 的 React# 假设仍位于 [fullstack-tutorial-root]/final/client/node_modules/apollo cd .. rm -Rf ./react ./react-dom ln -s [apollo-client-root]/node_modules/react ln -s [apollo-client-root]/node_modules/react-dom5. 启动 fullstack tutorial服务端终端一# 假设仍位于 [fullstack-tutorial-root]/final/client/node_modules cd ../../server npm start客户端终端二cd [fullstack-tutorial-root]/final/client npm start6. 在另一个终端启动 Apollo Client 的监听构建cd [apollo-client-root] npm run watch7. 验证改动是否实时生效# 假设仍位于 [apollo-client-root] cd src echo console.log(it worked); index.ts访问 http://localhost:3000/ 并打开浏览器开发者控制台。Apollo Client 重新构建完成后应能看到it worked输出说明 checkout 已成功接入应用。AI 贡献指南负责任地使用 AI 工具随着 AI 辅助编程工具普及AI 生成的 Issue 与 PR 越来越多而其审阅往往比传统贡献消耗更多维护者带宽。Apollo Client 认可 AI 工具的价值但要求贡献者负责任地使用提交 PR 前必须亲自 review AI 生成的代码只提交你真正理解的 Issue 与 PR——维护者常会追问设计选择与复现细节你需要能够解释清楚不要忽略 Issue 模板先开 Issue 与维护者讨论解决方案达成共识后再开 PR避免在评论中使用 AI 生成内容尤其是回应维护者反馈时。LLM 倾向于逐字采纳维护者反馈并直接改代码而不做进一步讨论这会造成大量返工维护者更愿意与英语不完美但真实的人交流而不是直接与 agent 对话不要提交为问题寻找方案的 AI 生成 Issue/PRIssue 必须包含完整的端到端复现、生产环境中遇到的问题以及相关上下文在 Issue 中留言表明你想通过 PR 修复它避免不同贡献者重复提交同一个 PR。无视这些准则的 PR 与 Issue 可能会被维护者酌情关闭。从仓库中也能看到项目对 AI 辅助编码生态是认真对待的——例如 eslint-local-rules 中定义了如require-using-disposable、forbid-act-in-disabled-act-environment等针对测试质量的本地 ESLint 规则以及 docs/agent-skills 下为 Agent 准备的开发技能文档说明项目正在系统性规范人机协作的开发流程。小结Apollo Client 的贡献流程可以用一句话概括先达成共识再写代码测试必须齐全changeset 不可遗漏。无论你贡献的是文档、小型修复还是大型特性遵循 Issue 规范、changeset 机制与代码审查六条标准都能显著提升 PR 被合并的效率。从仓库根目录的 CONTRIBUTING.md、CLAUDE.md、package.json 与 config/jest.config.ts 出发你可以完整还原项目的开发、测试与发布全貌并结合 CHANGELOG.md 观察每次发布的 changeset 沉淀。赞分享前端GraphQL【免费下载链接】apollo-clientThe industry-leading GraphQL client for TypeScript, JavaScript, React, Vue, Angular, and more. Apollo Client delivers powerful caching, intuitive APIs, and comprehensive developer tools to accelerate your app development.项目地址https://gitcode.com/gh_mirrors/ap/apollo-client点击查看免费下载相关推荐深入解读 Slint 贡献指南从 Issue 到合并的完整参与流程深入解读 Slint 贡献指南从 Issue 到合并的完整参与流程 Slint 是一个开源的声明式 GUI 工具包面向 Rust、C、JavaScrip前端UI组件桌面应用嵌入式移动开发跨平台k6 贡献者指南从 Issue 到合并的完整参与流程与工程规范k6 贡献者指南从 Issue 到合并的完整参与流程与工程规范 本篇指南基于 k6 仓库的 CONTRIBUTING.md https://link.gitc测试开发工具CI/CDjsdiff开发贡献指南从Issue提交到PR合并的完整流程jsdiff开发贡献指南从Issue提交到PR合并的完整流程 项目概述 jsdiff是一个JavaScript文本差异比较库A javascript tex开发者工具版本控制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Apollo Client 贡献指南：从 Issue 到合并发布的完整参与流程
前端GraphQL【免费下载链接】apollo-clientThe industry-leading GraphQL client for TypeScript, JavaScript, React, Vue, Angular, and more. Apollo Client delivers powerful caching, intuitive APIs, and comprehensive developer tools to accelerate your app development.项目地址https://gitcode.com/gh_mirrors/ap/apollo-client点击查看免费下载Apollo Client 是 Apollo GraphQL 生态中最核心的开源项目之一它以 npm workspace 单仓库monorepo的形式维护主包、codegen 与 codemods 等多个工作区。本篇指南基于仓库根目录的 CONTRIBUTING.md 展开系统讲解社区贡献者从报告 Issue、提交 PR、编写 changeset到本地构建、测试、联调真实应用的完整路径并结合当前仓库的源码与配置文件给出可验证的实操细节。读完本文你将掌握 Apollo Client 的贡献流程、开发命令体系与 AI 辅助编程时代下的协作规范能够以符合项目要求的方式提交第一个高质量 PR。参与方式总览由易到难的六条路径Apollo Client 欢迎任何经验水平的开发者参与官方将贡献方式按难度从低到高排列如下报告 bug填写规范化的 Issue附上可复现的最小案例改进文档修正错别字、补充示例或重写文档段落响应他人 Issue帮助社区成员定位问题、给出绕行方案编写 changeset为版本管理与 changelog 生成提供素材提交小型 bug 修复改动小于 20 行代码并附带测试建议新特性在特性请求仓库中提出设计讨论。此外还有大 PR路径大 bug 修复与新特性以及面向 AI 辅助编程的专门规范下文逐一展开。Issues高质量贡献的起点报告 bug三个必备要素要最大化问题被快速修复的概率bug 报告需要包含以下三项内容预期结果Intended outcome描述 bug 发生时你试图完成的目标并附上尽可能多的相关代码实际结果Actual outcome描述实际发生了什么包括相关错误信息、日志的截图或复制粘贴文本可重点查看浏览器控制台、服务端控制台与网络日志。请避免使用不工作坏了这类模糊表述复现步骤How to reproduce给出维护者或贡献者可以照做的复现指引越具体越好只提及复现 bug 所必需的信息并避免对根因的臆测。一个关键建议是用最小复现来隔离问题。在很多情况下构建最小复现的过程本身就会揭示 bug 的真正来源其实在库之外从而为所有人节省时间。改进文档与响应 Issue文档、示例与开源内容的改进是上手门槛最低的贡献方式。任何细微的改进都可以直接开 PR如果希望做大改或重写建议先在特性请求仓库中开一个 feature request 进行讨论再动手写 PR。响应他人 Issue 同样是重要贡献帮助分析问题、识别根因或提供 workaround。如果你希望在此过程中承担更积极的角色可以直接回复 Issue 并参与讨论。Changesets版本与发布的核心机制Apollo Client 使用 changesets 自动化版本管理和发布流程。任何包含代码改动的 PR 都必须附带一个 changeset本地在分支上运行npx changesetchangeset CLI 会引导你完成两步输入对应的 semver 版本提升类型major / minor / patch以及描述本次改动。你可以直接在命令行输入简短描述然后在.changeset目录下编辑生成的 Markdown 文件。编辑时可以使用 GitHub Flavored Markdown 的全部特性如列表、代码块、链接。需要注意你在 changeset 中填写的描述将被用于生成未来版本的CHANGELOG.md条目与发布说明因此描述越完整、越准确越好。从仓库配置看.changeset/config.json 声明了发布的基础行为changelog 使用changesets/changelog-github生成器并关联apollographql/apollo-client仓库access为public公开发布baseBranch为maincommit为false。发布流水线由 package.json 中的脚本驱动changeset-version应用 changeset 并更新依赖与changeset-publish构建后执行changeset publishCI 侧还有changeset-check用于检查是否遗漏 changeset。小型 bug 修复快车道对于改动少于 20 行代码的小型 bug 修复可以直接开 PR。维护者会尽快合并理想情况下当天发布新版本。唯一硬性要求是必须附带一个能够验证你所修复 bug 的测试。这与仓库的代码审查准则相呼应——测试是合并的门槛。建议新特性Apollo Client 的大多数特性都源自社区建议。特性建议与讨论类 Issue 已不再由当前仓库的 issue tracker 管理需要在特性请求仓库中新建 feature request / discussion本仓库中打开的这类 Issue 会被关闭。大 PR先设计共识再写代码大 PR 包括大型 bug 修复与新特性。这类改动风险高、未必总能合并因此项目要求先在设计上达成共识以减少可能的返工。完整流程共七步开 Issuebug 在当前仓库开feature request 在特性请求仓库开达成共识部分贡献者与社区成员应一致认为该 bug/特性重要且值得投入实现约定预期行为在 Issue 中明确修复到什么程度算修复新特性的开发者使用体验是什么样约定实现计划写出实现方案——需要新增或重写哪些模块一个 PR 还是多个增量 PR谁负责哪部分提交 PR如果改动依赖多个补丁请一次只提交一个否则在第一个被 review 和合并期间其他补丁可能过期。要避免顺手改式的无关变更——与本次改进无关的内容尤其是无关代码的格式调整应放入独立 PRReview至少一位核心贡献者签字认可后才能合并。提交前请先自我 review 一遍代码可以加速合并合并并发布。代码审查指南六条核心标准每一行进入 Apollo 包的代码都必须由至少一位熟悉该代码库的核心贡献者审查。审查重点关注CI 检查必须通过这是 review 的先决条件由 PR 作者负责测试不过PR 不会被 review简洁性Simplicity是否用最简单的方式达成目标文件过多、函数冗余、代码行过于复杂时应提出更简单方案。尤其要避免在简单、小巧、务实的修复足以解决问题时去实现一个过度通用的方案测试Testing测试能否保证代码在周边变化时不回归回归时新增测试能否帮助定位库的哪个部分出了问题是否覆盖了合适的边界情况新代码的所有重要代码路径是否至少被执行一次当前仓库的测试体量提供了天然参照——src下几乎每个模块都配对了__tests__目录例如 src/core/ApolloClient.ts 对应 src/core/tests测试矩阵横跨 React 17/18/19、GraphQL 16/17 与 RxJS 最小版本无冗余或无关改动PR 不应携带随机格式改动重构应尽量与 bug 修复或特性拆分到不同 PR恰当的注释代码应被注释或以清晰的自文档化方式编写符合语言惯例TypeScript 中要确保类型具体且正确ES2015 中优先使用 import 而非 require、使用 const 而非 var。项目还配置了严格的 ESLint 规则EXTENDED_RULES1 eslint --max-warnings 0与 Prettier 格式检查从工具层面强制多数惯例。本地开发环境构建与测试构建 Apollo Client一次性构建整个项目npm run build该命令由 package.json 的prebuild清理产物与build串联node config/build.ts会按序执行 config/build.ts 中定义的多步流水线包括prepareDist准备产物目录、addExports按package.json的 exports 生成入口、typescript调用tsc编译详见 config/compileTs.ts、babelTransformBabel 转换、updateVersion写入版本号、inlineInheritDoc、deprecateInternals内部 API 弃用标记、processInvariants处理 invariant 错误码与verifySourceMaps校验 source map等。构建产物输出到dist目录同时产出 ESM 与 CommonJS.cjs两种格式。如果是 monorepo 中的特定工作区CLAUDE.md 给出了示例npm run build -w codegen只构建 codegen 工作区见 codegen/package.json。运行测试一次性运行全部测试npm run test实际上npm test会以--expose-gc等 Node 参数启动 Jest并指向统一的 Jest 配置 config/jest.config.ts。监听模式运行全部测试npm run test:watch只运行指定测试直接调用 jest传入 jest 配置并用testRegex选项筛选jest --config ./config/jest.config.ts --testRegex __tests__/useQuery.test.tsx从 config/jest.config.ts 可以看到测试被组织为六个 Jest 项目并行运行Core Tests纯 TypeScript 核心逻辑测试ts-jest 转译不做类型检查类型检查由 CI 中的tsc完成Core Tests - RxJS min version用最小支持的 RxJS 版本rxjs-min即 7.3.0验证核心兼容性Core Tests - GraphQL 16将graphql映射到graphql-16包验证 GraphQL 16 兼容性ReactDOM 17 / 18 / 19三个 React 版本的项目通过moduleNameMapper将react、react-dom分别映射到react-17、react-18等别名其中 React 17 项目会忽略 Suspense 相关测试Suspense 仅支持 React 18。配套的npm run test:coverage含 lcov 覆盖率报告、npm run test:memory内存测试见 scripts/memory与npm run test:codegencodegen 集成测试覆盖了更深入的验证场景。代码质量与静态检查仓库在 CLAUDE.md 中归纳了完整的质量门禁命令合并前通常需要在本地跑通npm run typecheckTypeScript 类型检查含 integration-tests 的类型测试npm run lintESLint 严格规则检查--max-warnings 0npm run format/npm run check:formatPrettier 格式化与校验npm run knip检测未使用的文件与导出npm run madge检测循环依赖npm run bundlesize构建后校验包体积预算。这些检查与 CI 中的必过项共同构成了代码审查指南中Required CI checks pass的具体含义。将本地 checkout 链接到真实应用有时需要在真实应用中验证 Apollo Client 开发分支的改动效果。官方推荐的链路是以 Apollo fullstack 教程应用为宿主用符号链接把 checkout 接入应用。以下为完整步骤[apollo-client-root]代表 Apollo Client checkout 的根目录[fullstack-tutorial-root]代表教程应用的根目录。1. 克隆并安装 Apollo Clientgit clone apollo-client 仓库地址 cd apollo-client npm i cd ..2. 克隆并安装 fullstack tutorial服务端与客户端各自安装依赖git clone fullstack-tutorial 仓库地址 cd fullstack-tutorial cd final/server npm i cd ../client npm i3. 将应用的apollo/client指向 checkout 的编译产物# 假设仍位于 [fullstack-tutorial-root]/final/client cd node_modules/apollo rm -Rf ./client ln -s [apollo-client-root]/dist client这里的dist正是npm run build的输出目录对应 package.json 中main与module字段指向的位置。4. 若使用 React避免重复 React 版本导致的 hook 错误让应用复用 checkout 的 React# 假设仍位于 [fullstack-tutorial-root]/final/client/node_modules/apollo cd .. rm -Rf ./react ./react-dom ln -s [apollo-client-root]/node_modules/react ln -s [apollo-client-root]/node_modules/react-dom5. 启动 fullstack tutorial服务端终端一# 假设仍位于 [fullstack-tutorial-root]/final/client/node_modules cd ../../server npm start客户端终端二cd [fullstack-tutorial-root]/final/client npm start6. 在另一个终端启动 Apollo Client 的监听构建cd [apollo-client-root] npm run watch7. 验证改动是否实时生效# 假设仍位于 [apollo-client-root] cd src echo console.log(it worked); index.ts访问 http://localhost:3000/ 并打开浏览器开发者控制台。Apollo Client 重新构建完成后应能看到it worked输出说明 checkout 已成功接入应用。AI 贡献指南负责任地使用 AI 工具随着 AI 辅助编程工具普及AI 生成的 Issue 与 PR 越来越多而其审阅往往比传统贡献消耗更多维护者带宽。Apollo Client 认可 AI 工具的价值但要求贡献者负责任地使用提交 PR 前必须亲自 review AI 生成的代码只提交你真正理解的 Issue 与 PR——维护者常会追问设计选择与复现细节你需要能够解释清楚不要忽略 Issue 模板先开 Issue 与维护者讨论解决方案达成共识后再开 PR避免在评论中使用 AI 生成内容尤其是回应维护者反馈时。LLM 倾向于逐字采纳维护者反馈并直接改代码而不做进一步讨论这会造成大量返工维护者更愿意与英语不完美但真实的人交流而不是直接与 agent 对话不要提交为问题寻找方案的 AI 生成 Issue/PRIssue 必须包含完整的端到端复现、生产环境中遇到的问题以及相关上下文在 Issue 中留言表明你想通过 PR 修复它避免不同贡献者重复提交同一个 PR。无视这些准则的 PR 与 Issue 可能会被维护者酌情关闭。从仓库中也能看到项目对 AI 辅助编码生态是认真对待的——例如 eslint-local-rules 中定义了如require-using-disposable、forbid-act-in-disabled-act-environment等针对测试质量的本地 ESLint 规则以及 docs/agent-skills 下为 Agent 准备的开发技能文档说明项目正在系统性规范人机协作的开发流程。小结Apollo Client 的贡献流程可以用一句话概括先达成共识再写代码测试必须齐全changeset 不可遗漏。无论你贡献的是文档、小型修复还是大型特性遵循 Issue 规范、changeset 机制与代码审查六条标准都能显著提升 PR 被合并的效率。从仓库根目录的 CONTRIBUTING.md、CLAUDE.md、package.json 与 config/jest.config.ts 出发你可以完整还原项目的开发、测试与发布全貌并结合 CHANGELOG.md 观察每次发布的 changeset 沉淀。赞分享前端GraphQL【免费下载链接】apollo-clientThe industry-leading GraphQL client for TypeScript, JavaScript, React, Vue, Angular, and more. Apollo Client delivers powerful caching, intuitive APIs, and comprehensive developer tools to accelerate your app development.项目地址https://gitcode.com/gh_mirrors/ap/apollo-client点击查看免费下载相关推荐深入解读 Slint 贡献指南从 Issue 到合并的完整参与流程深入解读 Slint 贡献指南从 Issue 到合并的完整参与流程 Slint 是一个开源的声明式 GUI 工具包面向 Rust、C、JavaScrip前端UI组件桌面应用嵌入式移动开发跨平台k6 贡献者指南从 Issue 到合并的完整参与流程与工程规范k6 贡献者指南从 Issue 到合并的完整参与流程与工程规范 本篇指南基于 k6 仓库的 CONTRIBUTING.md https://link.gitc测试开发工具CI/CDjsdiff开发贡献指南从Issue提交到PR合并的完整流程jsdiff开发贡献指南从Issue提交到PR合并的完整流程 项目概述 jsdiff是一个JavaScript文本差异比较库A javascript tex开发者工具版本控制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
代码包深度解析与实践指南)
