恒美微站
首页
关于我们
建站服务
主题模板
案例展示
资讯中心
联系我们
Renovate Typst Manager:如何自动追踪并升级 .typ 文件中的 Typst 包版本
首页
资讯中心
/
Renovate Typst Manager:如何自动追踪并升级 .typ 文件中的 Typst 包版本
Renovate Typst Manager:如何自动追踪并升级 .typ 文件中的 Typst 包版本
发布时间:2026/9/13 2:41:03
Renovate Typst Manager如何自动追踪并升级 .typ 文件中的 Typst 包版本【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本文基于 Renovate 仓库中 Typst Manager 的官方文档lib/modules/manager/typst/readme.md及其配套源码展开。读完你将会知道Renovate 如何从.typ文档中识别 Typst 包导入#import语句、哪些命名空间会被真正更新、版本信息从哪里拉取、以及在不同托管平台上使用它时的认证注意事项。Manager 概览只认 .typ 文件只对接 typst 数据源Renovate 的 Typst Manager 职责很单一管理.typ文件中 Typst 包导入的版本并为其发起更新。Manager 的注册与默认配置定义在 lib/modules/manager/typst/index.ts 中export const displayName Typst package; export const defaultConfig { managerFilePatterns: [/\\.typ$/], }; export const supportedDatasources [TypstDatasource.id];从这段配置可以看出两个关键点文件匹配规则是managerFilePatterns: [/\\.typ$/]即仓库中所有以.typ结尾的文件都会被该 Manager 扫描。你无需额外配置Renovate 启用后就会自动纳入这些文件唯一支持的依赖数据源是TypstDatasourceid 为typstManager 与数据源之间是一一绑定的Manager 负责从哪里提取依赖数据源负责从哪里查版本。该 Manager 在模块注册表中挂载于 lib/modules/manager/api.tsapi.set(typst, typst)是 Renovate 全部包管理器之一。提取逻辑从 #import 语句中解析包名与版本核心提取函数位于 lib/modules/manager/typst/extract.ts。它的工作流程非常直接先用stripJsonComments去掉注释再按行切分文件内容对每一行应用一条全局正则匹配 Typst 的包导入语法const importRegex regEx( /#import\s(?namespace[^/])\/(?pkg[^:]):(?version[^])/g, );这条正则对应 Typst 的导入语句形态#import namespace/pkg:version: ...三个命名捕获组分别是namespace命名空间、pkg包名、version精确版本号。对每个命中提取结果会被组装成一条依赖记录const dep: PackageDependency { datasource: TypstDatasource.id, packageName: ${namespace}/${pkg}, // 例如 preview/tablex currentValue: version, // 例如 0.0.8 };也就是说packageName会保留命名空间/包名的完整形态而currentValue是导入语句中写死的精确版本。命名空间策略只有 preview 会被真正更新提取逻辑对命名空间有明确的分支处理这是使用 Typst Manager 时最容易踩坑的地方if (namespace preview) { dep.depName pkg; } if (namespace ! preview) { dep.skipReason namespace local ? local : unsupported; }preview命名空间正常参与更新depName取包名本身更新分支和 PR 标题将以包名呈现local命名空间本地包如#import local/mylib:1.2.3: helper被标记skipReason: localRenovate 不处理其他任意命名空间如custom被标记skipReason: unsupported同样不处理。这一点有完整的测试用例佐证。lib/modules/manager/typst/extract.spec.ts 覆盖了多种场景例如多导入提取const content #import preview/tablex:0.0.8: tablex, gridx #import preview/cetz:0.2.2: canvas, plot #import local/mylib:1.2.3: helper ;期望结果是preview/tablex、preview/cetz正常进入依赖列表而local/mylib带有skipReason: local。测试还验证了若干边界行为同一行出现多个#import也能全部提取正则带g标志非标准写法会被忽略例如#import regular/path: *无前缀、缺少#的import、以及缺少引号的#import preview/pkg:1.0.0: *预发布版本格式0.1.0-beta.1、2.1.0-alpha可以被原样提取交由版本比较模块处理。数据源实现版本列表从哪里来官方文档 lib/modules/manager/typst/readme.md 中说明Typst 数据源通过 GitHub API 从 typst/packages 仓库获取包信息GitHub 用户无需 tokenRenovate App 本身有访问权限而非 GitHub 平台Bitbucket、Azure DevOps、GitLab 等则必须配置 GitHub token否则查询会因 API 限流而失败。文档并指向了 docs/usage/mend-hosted/github-com-token.md 的 token 配置指南。需要说明的是当前源码的实现已经发生了变化从源码结构看lib/modules/datasource/typst/index.ts 中数据源的默认注册表 URL 为override readonly defaultRegistryUrls [ https://packages.typst.org/preview/index.json, ];即当前实现是直接请求 Typst 官方注册表的preview/index.json索引文件而非调用 GitHub API 拉取仓库数据。这意味着文档中非 GitHub 平台必须配置 GitHub token这一要求对应的是早期的实现方式就当前代码而言typst 数据源自身不依赖 GitHub API你在非 GitHub 平台上运行时该 token 约束是否仍然必要建议以最新官方文档说明为准。写作本文时请以 datasource 源码 为准理解实际的数据获取路径。数据源的工作流程数据源类TypstDatasource的关键行为见 lib/modules/datasource/typst/index.ts命名空间前置校验_getReleases先把packageName按/拆分若命名空间不是preview直接记一条 debug 日志并返回null——与提取侧的 skip 策略形成双重保险拉取注册表索引通过this.http.getJson(registryUrl, { cacheProvider }, Registry)请求preview/index.json并附带一个 HTTP 缓存提供者PackageHttpCacheProvider缓存命名空间datasource-typst:cache-provider避免每次都打远端按包名取结果以包名为 key 从解析后的注册表对象中取对应条目取不到则返回null取到后把registryUrl回填到结果中包级缓存外层getReleases用withCache再包一层缓存键为datasource-typst:registry-releases命名空间下的config.packageNamefallback: true同一包在不同文件/不同 run 间可复用查询结果。注册表 schemazod 校验与字段映射响应结构由 lib/modules/datasource/typst/schema.ts 中的 zod schema 定义并做字段映射const ReleaseItem z .object({ name: z.string().min(1), version: z.string().min(1), repository: z.string().url(), updatedAt: z.number(), }) .transform( ({ name: packageName, version, repository: sourceUrl, updatedAt }) { const releaseTimestamp asTimestamp(updatedAt); return { packageName, version, sourceUrl, releaseTimestamp }; }, );可以看到三个字段被显式映射name作为包名注册表条目按包名聚合、repository映射为sourceUrl用于在 PR 中展示包仓库地址、updatedAtUnix 秒经asTimestamp转换为 ISO 时间戳releaseTimestamp。updatedAt是判断发布年龄minimumReleaseAge的关键字段Renovate 据此可以识别刚发布的新版本。外层Registry是LooseArray(ReleaseItem).transform(...)注册表是一个数组多个条目通过result[packageName] ?? { releases: [] }聚合成包名 → 发布列表的字典因此同一个包的多个历史版本会被归并到同一条ReleaseResult.releases下。LooseArray包装意味着数组中个别畸形条目会被容错跳过而不是让整个注册表解析失败。数据源的行为边界由 lib/modules/datasource/typst/index.spec.ts 的测试固化正常多版本聚合、非preview命名空间返回null、包名在注册表中不存在返回null、远端 500 返回null、空数组返回null。版本比较semver-coerced数据源声明的默认版本比较策略是semver-coercedoverride defaultVersioning semver;import { id as semver } from ../../versioning/semver-coerced/index.ts;lib/modules/versioning/semver-coerced/index.ts 中的实现先用semver.coerce把版本字符串宽松地强制转成语义化版本再做比较、排序与 breaking 判定equals、isGreaterThan、isStable、isBreaking等均基于 coerce 后的结果。它不支持范围supportsRanges false这与 Typst 导入语句只写精确版本的使用方式相吻合。得益于 coerce 的宽松性类似0.0.8、带前缀或简写的版本串也能参与比较。实际效果与配置建议把提取、数据源、版本比较三段串起来一条典型的更新链路是Renovate 扫描到main.typ匹配/\.typ$/提取出#import preview/tablex:0.0.8: tablex, gridx对应的依赖preview/tablex0.0.8向https://packages.typst.org/preview/index.json查询tablex的全部发布记录用 semver-coerced 判断存在更高版本后把语句中的版本号替换为新值并创建 PR。由于该 Manager 使用defaultConfig中的文件模式默认情况下无需任何额外配置即可工作。若需要针对 Typst 依赖单独收紧策略例如只允许 minor 更新、或要求发布满一定天数再更新可以借助标准配置能力例如{ packageRules: [ { matchManagers: [typst], matchPackagePatterns: [^preview/], updateTypes: [minor, patch] } ] }示例仅演示packageRules的用法具体字段语义见 docs/usage/configuration-options.md。小结Renovate 的 Typst Manager 是一个小而完整的示例managerFilePatterns决定扫描范围extract.ts 用一条正则解析#import namespace/pkg:version语法并按命名空间preview/local/ 其他决定是否更新datasource 从 Typst 官方注册表拉取经 zod 校验的发布数据并做两级缓存semver-coerced 负责版本比较。阅读 lib/modules/manager/typst/readme.md 与上述源码即可完整掌握 Typst 依赖在 Renovate 中的更新机制与限制边界——尤其是只有preview命名空间的包会被实际升级这一核心约束。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考