Cypress 仓库如何判断第三方依赖该用 patch-package 还是重新发包【免费下载链接】cypressFast, easy and reliable testing for anything that runs in a browser.项目地址: https://gitcode.com/GitHub_Trending/cy/cypress在 cypress monorepo 里给不受自己控制的第三方依赖修 bug 或补功能时node_modules的改动无法直接提交到上游必须在本仓库侧持久化。仓库的维护指南 guides/patch-package.md 给出了三条路径并明确了各自的适用边界。这篇文章按先判断依赖所在位置、再选择持久化方式、最后补测试的顺序给出这个判断的完整操作路径。三条可选路径对第三方依赖做修改仓库文档中记录了三种方式Fork 该包到cypress-ioorg以 Git hash 方式安装在 NPM 的cypressorg 下重新发布打过补丁的版本在安装/构建时用patch-package工具对包打补丁。指南的结论是绝大多数情况下优先使用patch-package。文档列出的理由不用额外维护一个仓库或npm/包不用在 monorepo 的package.json/yarn.lock中同步维护版本号或 Git hash补丁改动可以在单个 PR 里完整评审而不是跨 2 个以上仓库绕开了 Yarn 在安装/缓存 Git 依赖时的一个 bug该 bug 会导致安装行为极其混乱。第一步判断依赖在哪里被安装patch-package有一个硬边界补丁目标必须会被打进 Cypress 二进制。cli和npm/目录下的包其传递依赖是由用户侧的包管理器安装的patch-package无法在这些依赖上生效。这就是唯一的分水岭依赖运行在构建后的 Cypress 二进制内如packages/driver、packages/server、packages/socket、packages/frontend-shared等→ 用patch-package依赖位于cli或npm/包的传递依赖中 → 只能在cypressorg 下重新发布打过补丁的 NPM 包。文档给出的实例是cypress/request它被 CLI 使用因此作为独立的 NPM 包维护。对第 1 条路径Fork Git hash文档还给出了一条额外限制任何npm/包都不能包含 Git 依赖因为并非所有用户都能安装 Git 依赖对应 issue #6752。所以发布到 NPM 的包里Fork 方案直接出局只剩重新发包这一种选择。判断顺序可以概括为先看依赖是否会进二进制会进二进制就patch-package不进去就检查它是否属于cli/npm/的传递依赖是则重新发包。patch-package 的落地方式选择patch-package后补丁文件放在仓库的patches/目录中。根目录patches/下当前就有 14 个此类文件命名形如http-proxy1.18.1.patch、evil-dns0.2.0.patch、bytenode1.3.7.dev.patch即包名版本号部分补丁带.dev后缀。各包也可以有自己的patches/目录例如cli/patches/、packages/driver/patches/。补丁在仓库安装时自动应用不需要手动执行packages/driver、packages/server、packages/socket、packages/frontend-shared的package.json中都有postinstall: patch-package根 package.json 的postinstall是node ./scripts/run-postInstall.js运行yarn时会触发完整 postinstall 流程patch-package、yarn-deduplicate、rebuild better-sqlite3、lerna build、V8 snapshot见 AGENTS.mdpatch-package在根package.json中以 devDependency 固定为8.0.1。环境前提同样来自 AGENTS.mdNode.js 22.19.0Yarn 1.22.22。新增或修改补丁后重新执行yarn让 postinstall 走一遍补丁即会应用到node_modules。补丁必须有测试指南中有一条硬性要求所有补丁都必须有测试。除了针对未构建版 Cypress 的常规单元/集成测试外至少要有一个针对已构建版本Cypress 的测试防止构建时补丁未按要求生效。文档给出三种方式任选其一即可写一个 binary-system-test在 system-tests/test-binary 中验证构建二进制里的补丁行为。文档中的示例test-binary/node-versions.spec.ts// ./test-binary/node-versions.spec.ts import systemTests from ../lib/system-tests import Fixtures from ../lib/fixtures describe(node versions, () { systemTests.it(runs in node 12, { dockerImage: cypress:node/12, project: todos, withBinary: true, }) })这类测试会先npm install生产 CLI 和构建出的 Cypress.zip再用真实的cypress run在 Docker 容器中执行CI 中对应binary-system-testsjob。在 scripts/binary/util/testStaticAssets.js 中添加断言确认补丁已被应用其他针对构建后二进制、在 CI 中运行的测试。验证运行方式来自 system-tests/README.mdyarn test-system # 运行全部 system 测试 # 或用 glob 定位单个 spec yarn test-system screenshot*element调试时还可追加--browser chrome --no-exit保持浏览器打开或加--cypress-inspect-brk调试被测的 Cypress 进程。补丁合并上游后移除如果补丁是通用性的不只服务于 Cypress 内部需求文档要求向依赖方的仓库提交 PR并在cypress仓库建一个跟踪 issue 关联上游 PR。上游合并后在 monorepo 中把该模块的版本号提升到已修复的版本然后删除补丁文件连同它的维护负担一起移除。这也是重新发包路径的对应收尾上游版本修复后可以把cypress下的 fork 版本替换回上游版本。小结判断规则依赖位置选择会打进 Cypress 二进制patch-package补丁放入对应patches/目录由postinstall应用cli或npm/包的传递依赖用户侧安装在cypressorg 下重新发包如cypress/request任何要发布到 NPM 的包不使用 Git 依赖形式的 Forkissue #6752两条路径的收尾动作相同补丁通用时先推上游上游合并后升级版本并移除本地补丁或 fork 包无论哪条路径补丁都必须配有至少一个针对构建后二进制的测试。【免费下载链接】cypressFast, easy and reliable testing for anything that runs in a browser.项目地址: https://gitcode.com/GitHub_Trending/cy/cypress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cypress 仓库如何判断第三方依赖该用 patch-package 还是重新发包
Cypress 仓库如何判断第三方依赖该用 patch-package 还是重新发包【免费下载链接】cypressFast, easy and reliable testing for anything that runs in a browser.项目地址: https://gitcode.com/GitHub_Trending/cy/cypress在 cypress monorepo 里给不受自己控制的第三方依赖修 bug 或补功能时node_modules的改动无法直接提交到上游必须在本仓库侧持久化。仓库的维护指南 guides/patch-package.md 给出了三条路径并明确了各自的适用边界。这篇文章按先判断依赖所在位置、再选择持久化方式、最后补测试的顺序给出这个判断的完整操作路径。三条可选路径对第三方依赖做修改仓库文档中记录了三种方式Fork 该包到cypress-ioorg以 Git hash 方式安装在 NPM 的cypressorg 下重新发布打过补丁的版本在安装/构建时用patch-package工具对包打补丁。指南的结论是绝大多数情况下优先使用patch-package。文档列出的理由不用额外维护一个仓库或npm/包不用在 monorepo 的package.json/yarn.lock中同步维护版本号或 Git hash补丁改动可以在单个 PR 里完整评审而不是跨 2 个以上仓库绕开了 Yarn 在安装/缓存 Git 依赖时的一个 bug该 bug 会导致安装行为极其混乱。第一步判断依赖在哪里被安装patch-package有一个硬边界补丁目标必须会被打进 Cypress 二进制。cli和npm/目录下的包其传递依赖是由用户侧的包管理器安装的patch-package无法在这些依赖上生效。这就是唯一的分水岭依赖运行在构建后的 Cypress 二进制内如packages/driver、packages/server、packages/socket、packages/frontend-shared等→ 用patch-package依赖位于cli或npm/包的传递依赖中 → 只能在cypressorg 下重新发布打过补丁的 NPM 包。文档给出的实例是cypress/request它被 CLI 使用因此作为独立的 NPM 包维护。对第 1 条路径Fork Git hash文档还给出了一条额外限制任何npm/包都不能包含 Git 依赖因为并非所有用户都能安装 Git 依赖对应 issue #6752。所以发布到 NPM 的包里Fork 方案直接出局只剩重新发包这一种选择。判断顺序可以概括为先看依赖是否会进二进制会进二进制就patch-package不进去就检查它是否属于cli/npm/的传递依赖是则重新发包。patch-package 的落地方式选择patch-package后补丁文件放在仓库的patches/目录中。根目录patches/下当前就有 14 个此类文件命名形如http-proxy1.18.1.patch、evil-dns0.2.0.patch、bytenode1.3.7.dev.patch即包名版本号部分补丁带.dev后缀。各包也可以有自己的patches/目录例如cli/patches/、packages/driver/patches/。补丁在仓库安装时自动应用不需要手动执行packages/driver、packages/server、packages/socket、packages/frontend-shared的package.json中都有postinstall: patch-package根 package.json 的postinstall是node ./scripts/run-postInstall.js运行yarn时会触发完整 postinstall 流程patch-package、yarn-deduplicate、rebuild better-sqlite3、lerna build、V8 snapshot见 AGENTS.mdpatch-package在根package.json中以 devDependency 固定为8.0.1。环境前提同样来自 AGENTS.mdNode.js 22.19.0Yarn 1.22.22。新增或修改补丁后重新执行yarn让 postinstall 走一遍补丁即会应用到node_modules。补丁必须有测试指南中有一条硬性要求所有补丁都必须有测试。除了针对未构建版 Cypress 的常规单元/集成测试外至少要有一个针对已构建版本Cypress 的测试防止构建时补丁未按要求生效。文档给出三种方式任选其一即可写一个 binary-system-test在 system-tests/test-binary 中验证构建二进制里的补丁行为。文档中的示例test-binary/node-versions.spec.ts// ./test-binary/node-versions.spec.ts import systemTests from ../lib/system-tests import Fixtures from ../lib/fixtures describe(node versions, () { systemTests.it(runs in node 12, { dockerImage: cypress:node/12, project: todos, withBinary: true, }) })这类测试会先npm install生产 CLI 和构建出的 Cypress.zip再用真实的cypress run在 Docker 容器中执行CI 中对应binary-system-testsjob。在 scripts/binary/util/testStaticAssets.js 中添加断言确认补丁已被应用其他针对构建后二进制、在 CI 中运行的测试。验证运行方式来自 system-tests/README.mdyarn test-system # 运行全部 system 测试 # 或用 glob 定位单个 spec yarn test-system screenshot*element调试时还可追加--browser chrome --no-exit保持浏览器打开或加--cypress-inspect-brk调试被测的 Cypress 进程。补丁合并上游后移除如果补丁是通用性的不只服务于 Cypress 内部需求文档要求向依赖方的仓库提交 PR并在cypress仓库建一个跟踪 issue 关联上游 PR。上游合并后在 monorepo 中把该模块的版本号提升到已修复的版本然后删除补丁文件连同它的维护负担一起移除。这也是重新发包路径的对应收尾上游版本修复后可以把cypress下的 fork 版本替换回上游版本。小结判断规则依赖位置选择会打进 Cypress 二进制patch-package补丁放入对应patches/目录由postinstall应用cli或npm/包的传递依赖用户侧安装在cypressorg 下重新发包如cypress/request任何要发布到 NPM 的包不使用 Git 依赖形式的 Forkissue #6752两条路径的收尾动作相同补丁通用时先推上游上游合并后升级版本并移除本地补丁或 fork 包无论哪条路径补丁都必须配有至少一个针对构建后二进制的测试。【免费下载链接】cypressFast, easy and reliable testing for anything that runs in a browser.项目地址: https://gitcode.com/GitHub_Trending/cy/cypress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考