Renovate 源码架构与开发指南从运行时流程到四大模块系统【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 是 Mend.io 出品的跨平台自动化依赖更新工具CLI它扫描仓库中的依赖清单文件、通过 datasource 查询新版本并自动创建 Pull Request 完成升级。本文以仓库根目录 CLAUDE.md即面向 AI Agent 的仓库指南为核心骨架结合 lib/renovate.ts、lib/workers/global/index.ts 与 lib/modules/ 下的真实源码完整讲解 Renovate 的运行时架构、模块化设计、关键目录职责、开发命令与贡献规范帮助读者快速建立对该代码库的整体认知并掌握从入口到最终产出 PR的完整调用链路。Renovate 是什么Renovate 是一个自动化的依赖更新工具核心工作方式是扫描扫描仓库中的依赖文件如package.json、pom.xml、Dockerfile等查询通过 datasource 查询这些依赖是否有更新的版本更新创建 Pull Request 来更新依赖版本。它支持 90 种包管理器并支持多种托管平台GitHub、GitLab、Bitbucket、Azure DevOps、Gitea、Forgejo、Gerrit 等。这一描述与仓库实际布局完全对应lib/modules/下同时存在 90 个 manager 实现与数十个 datasource / versioning / platform 实现。运行时架构六大阶段的处理流程CLAUDE.md 用一张 mermaid 流程图概括了 Renovate 的运行时流程这也是理解整个代码库的最佳入口各阶段职责如下阶段职责对应代码位置Entry Point程序入口初始化 OpenTelemetry 与日志解析早期 CLI 标志lib/renovate.tsGlobal Worker全局编排解析配置、初始化子模块、autodiscover 仓库、按仓库循环处理lib/workers/global/index.tsInit克隆仓库、读取仓库配置onboarding 检查等lib/workers/repository/init/Extract扫描并解析依赖文件产出PackageFile/PackageDependencylib/workers/repository/extract/Lookup拉取发布版本并做版本比较形成LookupUpdatelib/workers/repository/process/lookup/Update写回依赖文件、更新 lockfile、创建/更新 PRlib/workers/repository/update/Finalize清理分支、更新缓存然后进入下一个仓库lib/workers/repository/finalize/入口lib/renovate.tslib/renovate.ts 是程序的真实起点package.json 中start命令直接执行node lib/renovate.ts。它做了几件关键的事首先以动态 import 方式加载并初始化 OpenTelemetry 埋点./instrumentation/index.ts——注释明确要求此前的代码必须不能添加因为遥测必须先于日志库等被插桩的库生效初始化 bunyan 日志注册unhandledRejection兜底处理加载 lib/proxy.ts 完成代理引导调用parseEarlyFlags()处理--version/--help这类需要立即退出的参数实现在 lib/workers/global/config/parse/cli.ts最终调用全局 worker 的start()把退出码作为进程退出码返回并在结束时优雅关闭 OpenTelemetry。全局编排lib/workers/global/index.tslib/workers/global/index.ts 中的start()函数是架构图中Global Worker的具体实现其执行顺序与文档描述高度一致加载全局配置getGlobalConfig()调用parseConfigs(getEnv(), process.argv)把环境变量与 CLI 参数合并解析为统一配置对象对应lib/config/的解析逻辑初始化子模块globalInitialize(config)初始化平台连接、host rules 等对应 lib/workers/global/initialize.ts校验 presetvalidatePresets()通过resolveConfigPresets()解析并校验预设配置Autodiscover 仓库autodiscoverRepositories(config)在平台初始化之后枚举需要处理的仓库对应global -. autodiscover repos .- platform逐仓库串行处理for (const repository of config.repositories!)循环中调用repositoryWorker.renovateRepository(repoConfig)即 lib/workers/repository/index.ts每个仓库完成后通过finalize清理再进入下一个仓库——这正是流程图中finalize -- next repository -- init的含义。值得注意的细节每个仓库处理前会先由getRepositoryConfig()生成该仓库的局部配置localDir会指向baseDir/repos/platform/repoName并ensureDir并支持按仓库覆盖 hostRules、清理 HTTP 队列与限流器体现了全局配置 仓库级覆盖的分层设计。模块系统lib/modules/ 下的四大分类CLAUDE.md 指出lib/modules/下有四大模块类别每类都包含大量实现且每个类别根目录都有一个api.ts桶文件barrel file负责统一导出与注册。这一点在源码中可以得到完整验证。manager/ —— 依赖文件的识别与更新manager 负责检测并更新依赖文件例如 npm、maven、dockerfile、go-mod、cargo 等。每个 manager 从特定文件类型中提取依赖并知道如何更新它们。从 lib/modules/manager/api.ts 可以看到api.ts是一个Mapstring, ManagerApi通过api.set(npm, npm)、api.set(maven, maven)等方式注册了 90 个 manageransible、bazel、bun、cargo、circleci、composer、dockerfile、flux、github-actions、gitlabci、gomod、gradle、helmv3、kubernetes、maven、npm、nuget、pep621、pip_requirements、poetry、pub、terraform、vendir 等。每个 manager 目录下都有index.ts导出符合 lib/modules/manager/types.ts 中ManagerApi接口的实现。ManagerApi接口的核心方法见 lib/modules/manager/types.ts与架构图一一对应extractAllPackageFiles(config, files)/extractPackageFile(content, packageFile, config)—— 对应extract阶段产出PackageFile内含deps: PackageDependency[]updateDependency(updateDependencyConfig)—— 对应update阶段接收fileContent、packageFile与upgrade返回更新后的文件内容updateArtifacts(updateArtifact)—— 负责更新 lockfile 等产物文件supportsLockFileMaintenance与lockFileNames—— 声明是否支持 lockfile 维护及对应的 lockfile 文件名类型层面用交叉类型保证两者同时出现getRangeStrategy(config)—— 按依赖返回范围策略。datasource/ —— 从注册表拉取版本信息datasource 负责从各种注册表npm registry、Docker Hub、GitHub Releases、PyPI 等获取版本/发布信息。与 manager 类似lib/modules/datasource/api.ts 也采用注册表模式注册了 apk、artifactory、docker、github-tags、github-releases、gitlab-tags、helm、maven、npm、nuget、packagist、pypi、rubygems、terraform-provider 等数十个 datasource。lib/modules/datasource/types.ts 定义了DatasourceApi接口核心是getReleases(config: GetReleasesConfig): PromiseReleaseResult | null—— 返回ReleaseResult含releases: Release[]、tags、sourceUrl、registryUrl等元数据对应lookup阶段的fetch releasesgetDigest(config, newValue)—— 获取 digest适用于 Docker 镜像等defaultRegistryUrls/customRegistrySupport—— 默认注册表地址与是否允许自定义注册表registryStrategy—— 多注册表查询策略first只查第一个、hunt按序尝试直到拿到非空结果、merge合并去重所有注册表结果caching—— 是否由 datasource 索引层做集中缓存置为true的前提是 datasource 能返回isPrivate标志postprocessRelease(config, release)—— 在候选版本形成时做二次校验可返回reject拒绝该版本并让系统尝试下一个候选如检测到 yanked 版本。versioning/ —— 按生态解析与比较版本versioning 负责按各生态的规则解析和比较版本字符串semver、docker、maven、pep440 等。lib/modules/versioning/types.ts 定义了VersioningApi接口几乎所有版本运算能力都集中于此校验类isValid、isVersion、isSingleVersion用于 pinning 判断、isStable、isCompatible例如 Docker 的1.2.3与1.2.4-alpine被视为不兼容分解类getMajor/getMinor/getPatch比较类equals、isGreaterThan、getSatisfyingVersion、minSatisfyingVersion、sortVersions、matches、subset/intersects范围运算getNewValue(newValueConfig)—— 根据当前范围、rangeStrategy与新旧版本计算出新范围约束是 lookup 阶段compare versions与最终写回的关键。仓库中已有 semver、npm、docker、maven、pythonpep440、ruby、hashicorp、node、loose、regex 等 60 个 versioning 实现见 lib/modules/versioning/。platform/ —— 与代码托管平台交互platform 负责与 Git 托管平台 API 交互GitHub、GitLab、Bitbucket、Azure DevOps、Gitea、Forgejo、Gerrit 等承担 PR、Issue、评论等操作。lib/modules/platform/types.ts 中的PlatformParams/PlatformResult/RepoParams/Pr等接口定义了统一的平台抽象lib/modules/platform/api.ts 则按平台名github、gitlab、bitbucket、azure、gitea、forgejo、gerrit 等注册实现。平台抽象统一了如下操作架构图中虚线init/platform、update/platform、finalize/platform均落到这里仓库级操作初始化仓库initRepo返回RepoResult含defaultBranch、isFork、repoFingerprint、获取分支、ensureBranchPR 级操作getPrList/createPr/updatePr/mergePr、ensureComment、getBranchStatusCI 状态等除此之外仓库还提供default-scm与scm抽象见 lib/modules/platform/scm.ts用于 git 层操作。统一的 ModuleApi 基础接口四大模块的实现都继承自公共的ModuleApi基类定义于 lib/types/base.ts 附近的类型体系中保证各模块具备一致的生命周期与对外契约而api.ts桶文件的存在使得上层 worker 可以按字符串 id 动态取用任意模块实现这是 Renovate 高扩展性的根基。其他关键目录除lib/modules/外CLAUDE.md 还明确了以下目录职责均可在仓库中直接对应目录职责lib/config/配置解析、校验、默认值与 preset 解析含 migrations、validation、secrets 等子模块lib/util/共享工具HTTP、git、缓存、正则、模板、host-rules、压缩、加密等lib/workers/global/顶层编排autodiscovery、配置加载、全局初始化lib/workers/repository/单仓库处理流水线init / extract / process / update / finalize 等lib/constants/共享常量平台列表、错误消息、分类等tools/构建工具、文档生成、schema 生成、自定义 lint 规则其中 lib/workers/repository/ 是单仓库处理流水线的真实落点index.ts编排init/克隆与配置、config-migration/配置迁移、onboarding/onboarding PR、extract/提取依赖、process/lookup 与分支处理、update/写回与 PR、finalize/收尾等子流程与架构图中 Init → Extract → Lookup → Update → Finalize 完全对应。生成文件规则CLAUDE.md 特别强调lib/下匹配*.generated.ts的文件是构建期间自动生成的通过pnpm generate:*禁止直接编辑。仓库中相关生成脚本位于 tools/如tools/generate-imports.mjs、tools/generate-schema.ts、tools/generate-docs.ts等修改这些文件应改其生成源再重新执行生成命令。本地开发命令与环境仓库统一使用pnpm而非 npm/npx相关命令在 package.json 中均有定义命令作用pnpm install安装依赖pnpm check --all 可选路径Lint / 测试 / 自动修复pnpm test运行完整测试套件lint schema 校验 全部测试pnpm start或node lib/renovate.ts从源码直接运行 Renovate测试框架使用 Vitest通过pnpm vitest调用测试文件统一以.spec.ts后缀命名并与被测源码同目录存放co-located。测试环境中可直接使用jest-extended与expect-more-jest提供的全局断言。构建相关说明可进一步参考 docs/development/local-development.md。开发规范与贡献须知代码风格CLAUDE.md 明确要求开发前必读 docs/development/best-practices.md。该文档是仓库的核心编码规范要点包括分支命名遵循 Conventional Commits 作用域前缀如feat/13732-cacache-cleanup、fix/15431-gitea-automerge-strategy避免patch-1这类无意义命名函数风格优先完整函数声明function foo() {}而非const func (): void {}以获得更好的可读性与调用栈仅在需要动态绑定this时使用箭头函数表达式类型声明优先interface而非type避免使用 TypeScriptenum改用联合类型或不可变对象优先satisfies运算符而非as类型守卫避免Boolean使用sindresorhus/is包提供的is.string等is函数代码可读性宁可写冗长但易读的代码如用for循环替代难懂的reduce也不追求聪明的短代码。测试与覆盖率PR 要求100% 测试覆盖率/* v8 ignore ... */注释只能少量用于测试无法证明任何东西的不可达分支且必须使用描述性注释如/* v8 ignore next -- can never happen */不要写行数V8 不识别next 3这类计数测试文件与源码同目录放置使用.spec.ts后缀。PR 流程禁止 force pushPR 分支创建 PR 前必须完整阅读 .github/pull_request_template.md位于仓库.github/目录并严格使用其章节结构填写 PR 正文PR 应先以draft状态提交待 CLA 签署且作者确认改动就绪后再标记为 ready。问题与功能请求渠道仓库对 Issue 创建有严格限制非管理员创建 Issue 会被封禁因此问题/功能请求必须通过仓库的GitHub Discussions提交并使用对应的讨论模板Request help模板用于缺陷、疑问与异常行为需附最小复现与相关日志Suggest an idea模板用于功能请求与改进。安全漏洞不得在 GitHub 上报告需遵循 SECURITY.md 中的流程。总结以 CLAUDE.md 为索引可以清晰地勾勒出 Renovate 代码库的全貌一条从lib/renovate.ts入口出发、经 Global Worker 编排与 autodiscovery、再进入单仓库六阶段流水线的运行时主线一套以api.ts桶文件统一注册、四大模块manager / datasource / versioning / platform各司其职的高度模块化设计以及围绕配置、工具、worker 与构建脚本展开的目录体系。对于想要深入源码的开发者建议按入口 → 全局编排 → 单仓库流水线 → 单个模块实现的顺序阅读并结合 docs/development/ 下的最佳实践与各模块文档如 docs/development/adding-a-package-manager.md快速上手。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Renovate 源码架构与开发指南：从运行时流程到四大模块系统
Renovate 源码架构与开发指南从运行时流程到四大模块系统【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 是 Mend.io 出品的跨平台自动化依赖更新工具CLI它扫描仓库中的依赖清单文件、通过 datasource 查询新版本并自动创建 Pull Request 完成升级。本文以仓库根目录 CLAUDE.md即面向 AI Agent 的仓库指南为核心骨架结合 lib/renovate.ts、lib/workers/global/index.ts 与 lib/modules/ 下的真实源码完整讲解 Renovate 的运行时架构、模块化设计、关键目录职责、开发命令与贡献规范帮助读者快速建立对该代码库的整体认知并掌握从入口到最终产出 PR的完整调用链路。Renovate 是什么Renovate 是一个自动化的依赖更新工具核心工作方式是扫描扫描仓库中的依赖文件如package.json、pom.xml、Dockerfile等查询通过 datasource 查询这些依赖是否有更新的版本更新创建 Pull Request 来更新依赖版本。它支持 90 种包管理器并支持多种托管平台GitHub、GitLab、Bitbucket、Azure DevOps、Gitea、Forgejo、Gerrit 等。这一描述与仓库实际布局完全对应lib/modules/下同时存在 90 个 manager 实现与数十个 datasource / versioning / platform 实现。运行时架构六大阶段的处理流程CLAUDE.md 用一张 mermaid 流程图概括了 Renovate 的运行时流程这也是理解整个代码库的最佳入口各阶段职责如下阶段职责对应代码位置Entry Point程序入口初始化 OpenTelemetry 与日志解析早期 CLI 标志lib/renovate.tsGlobal Worker全局编排解析配置、初始化子模块、autodiscover 仓库、按仓库循环处理lib/workers/global/index.tsInit克隆仓库、读取仓库配置onboarding 检查等lib/workers/repository/init/Extract扫描并解析依赖文件产出PackageFile/PackageDependencylib/workers/repository/extract/Lookup拉取发布版本并做版本比较形成LookupUpdatelib/workers/repository/process/lookup/Update写回依赖文件、更新 lockfile、创建/更新 PRlib/workers/repository/update/Finalize清理分支、更新缓存然后进入下一个仓库lib/workers/repository/finalize/入口lib/renovate.tslib/renovate.ts 是程序的真实起点package.json 中start命令直接执行node lib/renovate.ts。它做了几件关键的事首先以动态 import 方式加载并初始化 OpenTelemetry 埋点./instrumentation/index.ts——注释明确要求此前的代码必须不能添加因为遥测必须先于日志库等被插桩的库生效初始化 bunyan 日志注册unhandledRejection兜底处理加载 lib/proxy.ts 完成代理引导调用parseEarlyFlags()处理--version/--help这类需要立即退出的参数实现在 lib/workers/global/config/parse/cli.ts最终调用全局 worker 的start()把退出码作为进程退出码返回并在结束时优雅关闭 OpenTelemetry。全局编排lib/workers/global/index.tslib/workers/global/index.ts 中的start()函数是架构图中Global Worker的具体实现其执行顺序与文档描述高度一致加载全局配置getGlobalConfig()调用parseConfigs(getEnv(), process.argv)把环境变量与 CLI 参数合并解析为统一配置对象对应lib/config/的解析逻辑初始化子模块globalInitialize(config)初始化平台连接、host rules 等对应 lib/workers/global/initialize.ts校验 presetvalidatePresets()通过resolveConfigPresets()解析并校验预设配置Autodiscover 仓库autodiscoverRepositories(config)在平台初始化之后枚举需要处理的仓库对应global -. autodiscover repos .- platform逐仓库串行处理for (const repository of config.repositories!)循环中调用repositoryWorker.renovateRepository(repoConfig)即 lib/workers/repository/index.ts每个仓库完成后通过finalize清理再进入下一个仓库——这正是流程图中finalize -- next repository -- init的含义。值得注意的细节每个仓库处理前会先由getRepositoryConfig()生成该仓库的局部配置localDir会指向baseDir/repos/platform/repoName并ensureDir并支持按仓库覆盖 hostRules、清理 HTTP 队列与限流器体现了全局配置 仓库级覆盖的分层设计。模块系统lib/modules/ 下的四大分类CLAUDE.md 指出lib/modules/下有四大模块类别每类都包含大量实现且每个类别根目录都有一个api.ts桶文件barrel file负责统一导出与注册。这一点在源码中可以得到完整验证。manager/ —— 依赖文件的识别与更新manager 负责检测并更新依赖文件例如 npm、maven、dockerfile、go-mod、cargo 等。每个 manager 从特定文件类型中提取依赖并知道如何更新它们。从 lib/modules/manager/api.ts 可以看到api.ts是一个Mapstring, ManagerApi通过api.set(npm, npm)、api.set(maven, maven)等方式注册了 90 个 manageransible、bazel、bun、cargo、circleci、composer、dockerfile、flux、github-actions、gitlabci、gomod、gradle、helmv3、kubernetes、maven、npm、nuget、pep621、pip_requirements、poetry、pub、terraform、vendir 等。每个 manager 目录下都有index.ts导出符合 lib/modules/manager/types.ts 中ManagerApi接口的实现。ManagerApi接口的核心方法见 lib/modules/manager/types.ts与架构图一一对应extractAllPackageFiles(config, files)/extractPackageFile(content, packageFile, config)—— 对应extract阶段产出PackageFile内含deps: PackageDependency[]updateDependency(updateDependencyConfig)—— 对应update阶段接收fileContent、packageFile与upgrade返回更新后的文件内容updateArtifacts(updateArtifact)—— 负责更新 lockfile 等产物文件supportsLockFileMaintenance与lockFileNames—— 声明是否支持 lockfile 维护及对应的 lockfile 文件名类型层面用交叉类型保证两者同时出现getRangeStrategy(config)—— 按依赖返回范围策略。datasource/ —— 从注册表拉取版本信息datasource 负责从各种注册表npm registry、Docker Hub、GitHub Releases、PyPI 等获取版本/发布信息。与 manager 类似lib/modules/datasource/api.ts 也采用注册表模式注册了 apk、artifactory、docker、github-tags、github-releases、gitlab-tags、helm、maven、npm、nuget、packagist、pypi、rubygems、terraform-provider 等数十个 datasource。lib/modules/datasource/types.ts 定义了DatasourceApi接口核心是getReleases(config: GetReleasesConfig): PromiseReleaseResult | null—— 返回ReleaseResult含releases: Release[]、tags、sourceUrl、registryUrl等元数据对应lookup阶段的fetch releasesgetDigest(config, newValue)—— 获取 digest适用于 Docker 镜像等defaultRegistryUrls/customRegistrySupport—— 默认注册表地址与是否允许自定义注册表registryStrategy—— 多注册表查询策略first只查第一个、hunt按序尝试直到拿到非空结果、merge合并去重所有注册表结果caching—— 是否由 datasource 索引层做集中缓存置为true的前提是 datasource 能返回isPrivate标志postprocessRelease(config, release)—— 在候选版本形成时做二次校验可返回reject拒绝该版本并让系统尝试下一个候选如检测到 yanked 版本。versioning/ —— 按生态解析与比较版本versioning 负责按各生态的规则解析和比较版本字符串semver、docker、maven、pep440 等。lib/modules/versioning/types.ts 定义了VersioningApi接口几乎所有版本运算能力都集中于此校验类isValid、isVersion、isSingleVersion用于 pinning 判断、isStable、isCompatible例如 Docker 的1.2.3与1.2.4-alpine被视为不兼容分解类getMajor/getMinor/getPatch比较类equals、isGreaterThan、getSatisfyingVersion、minSatisfyingVersion、sortVersions、matches、subset/intersects范围运算getNewValue(newValueConfig)—— 根据当前范围、rangeStrategy与新旧版本计算出新范围约束是 lookup 阶段compare versions与最终写回的关键。仓库中已有 semver、npm、docker、maven、pythonpep440、ruby、hashicorp、node、loose、regex 等 60 个 versioning 实现见 lib/modules/versioning/。platform/ —— 与代码托管平台交互platform 负责与 Git 托管平台 API 交互GitHub、GitLab、Bitbucket、Azure DevOps、Gitea、Forgejo、Gerrit 等承担 PR、Issue、评论等操作。lib/modules/platform/types.ts 中的PlatformParams/PlatformResult/RepoParams/Pr等接口定义了统一的平台抽象lib/modules/platform/api.ts 则按平台名github、gitlab、bitbucket、azure、gitea、forgejo、gerrit 等注册实现。平台抽象统一了如下操作架构图中虚线init/platform、update/platform、finalize/platform均落到这里仓库级操作初始化仓库initRepo返回RepoResult含defaultBranch、isFork、repoFingerprint、获取分支、ensureBranchPR 级操作getPrList/createPr/updatePr/mergePr、ensureComment、getBranchStatusCI 状态等除此之外仓库还提供default-scm与scm抽象见 lib/modules/platform/scm.ts用于 git 层操作。统一的 ModuleApi 基础接口四大模块的实现都继承自公共的ModuleApi基类定义于 lib/types/base.ts 附近的类型体系中保证各模块具备一致的生命周期与对外契约而api.ts桶文件的存在使得上层 worker 可以按字符串 id 动态取用任意模块实现这是 Renovate 高扩展性的根基。其他关键目录除lib/modules/外CLAUDE.md 还明确了以下目录职责均可在仓库中直接对应目录职责lib/config/配置解析、校验、默认值与 preset 解析含 migrations、validation、secrets 等子模块lib/util/共享工具HTTP、git、缓存、正则、模板、host-rules、压缩、加密等lib/workers/global/顶层编排autodiscovery、配置加载、全局初始化lib/workers/repository/单仓库处理流水线init / extract / process / update / finalize 等lib/constants/共享常量平台列表、错误消息、分类等tools/构建工具、文档生成、schema 生成、自定义 lint 规则其中 lib/workers/repository/ 是单仓库处理流水线的真实落点index.ts编排init/克隆与配置、config-migration/配置迁移、onboarding/onboarding PR、extract/提取依赖、process/lookup 与分支处理、update/写回与 PR、finalize/收尾等子流程与架构图中 Init → Extract → Lookup → Update → Finalize 完全对应。生成文件规则CLAUDE.md 特别强调lib/下匹配*.generated.ts的文件是构建期间自动生成的通过pnpm generate:*禁止直接编辑。仓库中相关生成脚本位于 tools/如tools/generate-imports.mjs、tools/generate-schema.ts、tools/generate-docs.ts等修改这些文件应改其生成源再重新执行生成命令。本地开发命令与环境仓库统一使用pnpm而非 npm/npx相关命令在 package.json 中均有定义命令作用pnpm install安装依赖pnpm check --all 可选路径Lint / 测试 / 自动修复pnpm test运行完整测试套件lint schema 校验 全部测试pnpm start或node lib/renovate.ts从源码直接运行 Renovate测试框架使用 Vitest通过pnpm vitest调用测试文件统一以.spec.ts后缀命名并与被测源码同目录存放co-located。测试环境中可直接使用jest-extended与expect-more-jest提供的全局断言。构建相关说明可进一步参考 docs/development/local-development.md。开发规范与贡献须知代码风格CLAUDE.md 明确要求开发前必读 docs/development/best-practices.md。该文档是仓库的核心编码规范要点包括分支命名遵循 Conventional Commits 作用域前缀如feat/13732-cacache-cleanup、fix/15431-gitea-automerge-strategy避免patch-1这类无意义命名函数风格优先完整函数声明function foo() {}而非const func (): void {}以获得更好的可读性与调用栈仅在需要动态绑定this时使用箭头函数表达式类型声明优先interface而非type避免使用 TypeScriptenum改用联合类型或不可变对象优先satisfies运算符而非as类型守卫避免Boolean使用sindresorhus/is包提供的is.string等is函数代码可读性宁可写冗长但易读的代码如用for循环替代难懂的reduce也不追求聪明的短代码。测试与覆盖率PR 要求100% 测试覆盖率/* v8 ignore ... */注释只能少量用于测试无法证明任何东西的不可达分支且必须使用描述性注释如/* v8 ignore next -- can never happen */不要写行数V8 不识别next 3这类计数测试文件与源码同目录放置使用.spec.ts后缀。PR 流程禁止 force pushPR 分支创建 PR 前必须完整阅读 .github/pull_request_template.md位于仓库.github/目录并严格使用其章节结构填写 PR 正文PR 应先以draft状态提交待 CLA 签署且作者确认改动就绪后再标记为 ready。问题与功能请求渠道仓库对 Issue 创建有严格限制非管理员创建 Issue 会被封禁因此问题/功能请求必须通过仓库的GitHub Discussions提交并使用对应的讨论模板Request help模板用于缺陷、疑问与异常行为需附最小复现与相关日志Suggest an idea模板用于功能请求与改进。安全漏洞不得在 GitHub 上报告需遵循 SECURITY.md 中的流程。总结以 CLAUDE.md 为索引可以清晰地勾勒出 Renovate 代码库的全貌一条从lib/renovate.ts入口出发、经 Global Worker 编排与 autodiscovery、再进入单仓库六阶段流水线的运行时主线一套以api.ts桶文件统一注册、四大模块manager / datasource / versioning / platform各司其职的高度模块化设计以及围绕配置、工具、worker 与构建脚本展开的目录体系。对于想要深入源码的开发者建议按入口 → 全局编排 → 单仓库流水线 → 单个模块实现的顺序阅读并结合 docs/development/ 下的最佳实践与各模块文档如 docs/development/adding-a-package-manager.md快速上手。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考