Remotion 文档发布流程如何把 PR 中的 AvailableFrom 更新为下一个补丁版本【免费下载链接】remotion Make videos programmatically with React项目地址: https://gitcode.com/GitHub_Trending/re/remotion在 Remotion 仓库中每一篇文档页面都可以用AvailableFrom v...组件标注某个 API、命令或功能是从哪个版本开始可用的。当 PR 包含文档改动且引入了新的AvailableFrom标注时其取值必须反映下一个将发布的版本而不是main分支上已经存在的旧版本。本文以仓库中.agents/skills/update-version/SKILL.md这份 Agent 技能文档为核心完整讲解这套取main版本 → 计算下一个补丁版本 → 只改本 PR 触及的条目 → 提交推送的操作流程并结合packages/core/src/version.ts、packages/docs/src/components/AvailableFrom.tsx、根目录set-version.ts等源码说明每个步骤背后的版本管理机制读完你可以独立完成 Remotion 文档 PR 的版本标注修正。一、背景AvailableFrom在 Remotion 文档中的作用AvailableFrom是 Remotion 文档站点位于packages/docs自定义的 MDX 全局组件。它的作用是在文档段落旁渲染一个版本徽标并指向该版本的 Release 页面让读者一眼看出这个功能从 v 多少开始可用。组件实现在 AvailableFrom.tsx关键行为有三点v属性必填源码中如果v为空会直接throw new Error(v is required)意味着文档构建期就能暴露缺失的版本标注容忍v前缀if (v.startsWith(v)) { v v.slice(1); }即写v4.0.469和v4.0.469效果一致渲染为 Release 链接组件最终输出一个ahref指向对应 GitHub Release 页面v${v}形式的 tag 路径徽标上显示v{v}鼠标悬停提示Added in v{v}。该组件通过 Docusaurus 的主题扩展注册为全局 MDX 组件MDXComponents.js 将AvailableFrom连同MinNodeVersion、MinBunVersion、MinEslintVersion等一并导出因此任意.mdx文档都可直接使用AvailableFrom v... /无需 import。仓库中大量文档页面如packages/docs/docs/animatedimage.mdx、packages/docs/docs/bundle.mdx等都在用它。理解了组件的渲染语义后就能明白版本取值为什么重要v的值会被直接拼进 Release 链接。如果填了一个尚未发布的版本号链接指向一个不存在的 tag如果填了main上已发布的旧版本号则会误导读者以为该功能是旧版本就有的。二、为什么是main版本 0.0.1Remotion 的版本模型要理解 update-version 技能的计算规则main的VERSION加 1 个补丁位需要先看清 Remotion 仓库的版本管理链条1. 版本号的唯一事实来源是packages/core/src/version.ts。该文件内容非常短见 version.ts// Automatically generated on publish export const VERSION 4.0.520;文件头部注释 Automatically generated on publish 说明它不是手工维护的——每次发布时由脚本重新生成。2. 生成逻辑在packages/core/ensure-correct-version.ts。ensure-correct-version.ts 会读取packages/core/package.json中的version字段重新写出src/version.ts然后执行构建bun run make与类型检查并校验dist/esm/version.mjs、dist/cjs/version.js两份产物中都确实包含了新版本号任何一个缺失都会process.exit(1)。这保证了package.json、源码常量、构建产物三处版本严格一致。3. 发布时由根目录set-version.ts统一抬升所有包。set-version.ts 是发布脚本用法bun set-version.mjs 4.0.178它要求当前在main分支上遍历packages/下所有含package.json的目录外加cloudrun/container把每个应发布包的version写成新版本随后依次触发 core 与 media-parser 的ensure-correct-version.ts校验、全仓库构建、packages/it-tests的版本一致性测试最后git add .提交一个vversion的 commit 并打 tag。4. 补丁版本递增是 Remotion 的既定发布节奏。仓库中另一份配套技能 version/SKILL.md 明确了这一前提We are working on the next version of Remotion. The current version can be found inpackages/core/src/version.ts.The next version is going to be a patch version.Ensure the docs correctly reference the next version.即main上的VERSION是最近一次已发布的版本下一个版本一定是 patch 1。update-version 技能正是在这个前提下工作的——文档 PR 中新增的AvailableFrom应该指向即将包含这些改动的那次发布也就是main版本 0.0.1。三、操作流程五步完成 PR 中AvailableFrom的版本更新以下流程完整继承自 update-version/SKILL.md适用于PR 包含packages/docs下的文档改动其中带有AvailableFrom v...且取值应反映下一个发布版本的场景。步骤 1获取main分支的规范版本号git fetch origin main --quiet git --no-pager show origin/main:packages/core/src/version.ts从输出中读出VERSION常量例如4.0.468然后把 patch 位加 1得到下一个补丁版本4.0.469。两点细节值得注意使用git show origin/main:...直接读取远端main的文件内容而不是读本地工作区——你的 PR 分支可能落后于main本地文件可能过期必须以远端为准只读取、不修改version.ts它由发布流程set-version.ts→ensure-correct-version.ts自动维护文档 PR 不应触碰。步骤 2定位当前 PR 改动的AvailableFrom条目git --no-pager diff origin/main...HEAD -- packages/docs | rg AvailableFrom v这条命令有三个精确约束缺一不可origin/main...HEAD三点 diff 只统计本 PR 相对main的分叉点引入的改动排除main上其他 PR 的变化-- packages/docs把范围限定在文档目录AvailableFrom只出现在文档源码中rg AvailableFrom v只保留含版本标注的行快速得到待核对清单含文件路径与行上下文。步骤 3只更新本 PR 触及的AvailableFrom取值将步骤 2 中列出的条目其v属性统一改为步骤 1 计算出的下一个补丁版本如4.0.469。写法上v4.0.469与vv4.0.469均可——从 AvailableFrom.tsx 的源码看组件会自动剥离v前缀。步骤 4不要改动 PR diff 之外的AvailableFrom这是技能文档中明确写出的红线全仓库有成百上千处AvailableFrom标注仅packages/docs/docs下的.mdx就有大量命中其中绝大多数对应的是早已发布的历史功能。它们的v值是该功能首次可用版本的准确记录与当前发布版本无关。只改本 PR diff 中的条目可以避免一次 PR 引入与主题无关的海量文档噪音也让 diff 评审聚焦于本次改动。步骤 5提交并推送将更新后的文档改动 commit 并 push 到当前 PR 分支。至此PR 中新增功能标注的版本号就与下一个实际会发布的版本号对齐了等main合入、执行bun set-version.ts version发布时main上的VERSION正好推进到该值文档标注随即变为已发布版本Release 链接也真实可达。四、与发布脚本的联动版本推进的完整闭环把 update-version 技能放回整个发布链路中看它其实是文档侧的一次预对齐文档 PR 阶段AvailableFrom标注为main版本 0.0.1本文流程合入main后正式发布时由 set-version.ts 把所有包的package.json抬升到同一新版本例如4.0.469它内部会跳过 featured 模板目录、按shouldReleasePackage策略过滤不需要发布的包策略来自packages/studio-shared/src/release-package-policy随后调用ensure-correct-version.ts重建version.ts并校验产物set-version.ts末尾还会git add . git commit -m vversion并打 tag——AvailableFrom组件指向的正是这类vversiontag形成文档徽标 → Release tag的闭环。换句话说如果文档 PR 把AvailableFrom写成了main上的旧版本号发布完成后该徽标会指向一个早于功能实际可用的 Release语义错误且难以追溯如果写成更大的未来版本Release 链接在发布时点又暂时 404。main 0.0.1 恰好是两边都不出错的唯一取值。五、实践要点小结唯一事实来源packages/core/src/version.ts的VERSION常量由 ensure-correct-version.ts 在发布时自动生成不要手工编辑它取值公式下一个补丁版本 main的VERSIONpatch 位 1前提是 Remotion 当前按 patch 节奏迭代见 .agents/skills/version/SKILL.md改动边界只改git diff origin/main...HEAD -- packages/docs命中的AvailableFrom v...其余条目一律不动格式容错v前缀可加可不加组件源码会自动剥离v为空会在渲染/构建时抛错渲染语义v值会直接拼进 GitHub Release 链接见 AvailableFrom.tsx 中href的构造所以取值必须对应一个真实存在的版本。这套流程把文档标注与版本发布两个本来异步的动作精确对齐文档 PR 提前把版本号预置到下一个补丁版本发布脚本随后把版本号推到同一值最终读者在文档中看到的版本徽标与 Release tag 严格一一对应。【免费下载链接】remotion Make videos programmatically with React项目地址: https://gitcode.com/GitHub_Trending/re/remotion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Remotion 文档发布流程：如何把 PR 中的 AvailableFrom 更新为下一个补丁版本
Remotion 文档发布流程如何把 PR 中的 AvailableFrom 更新为下一个补丁版本【免费下载链接】remotion Make videos programmatically with React项目地址: https://gitcode.com/GitHub_Trending/re/remotion在 Remotion 仓库中每一篇文档页面都可以用AvailableFrom v...组件标注某个 API、命令或功能是从哪个版本开始可用的。当 PR 包含文档改动且引入了新的AvailableFrom标注时其取值必须反映下一个将发布的版本而不是main分支上已经存在的旧版本。本文以仓库中.agents/skills/update-version/SKILL.md这份 Agent 技能文档为核心完整讲解这套取main版本 → 计算下一个补丁版本 → 只改本 PR 触及的条目 → 提交推送的操作流程并结合packages/core/src/version.ts、packages/docs/src/components/AvailableFrom.tsx、根目录set-version.ts等源码说明每个步骤背后的版本管理机制读完你可以独立完成 Remotion 文档 PR 的版本标注修正。一、背景AvailableFrom在 Remotion 文档中的作用AvailableFrom是 Remotion 文档站点位于packages/docs自定义的 MDX 全局组件。它的作用是在文档段落旁渲染一个版本徽标并指向该版本的 Release 页面让读者一眼看出这个功能从 v 多少开始可用。组件实现在 AvailableFrom.tsx关键行为有三点v属性必填源码中如果v为空会直接throw new Error(v is required)意味着文档构建期就能暴露缺失的版本标注容忍v前缀if (v.startsWith(v)) { v v.slice(1); }即写v4.0.469和v4.0.469效果一致渲染为 Release 链接组件最终输出一个ahref指向对应 GitHub Release 页面v${v}形式的 tag 路径徽标上显示v{v}鼠标悬停提示Added in v{v}。该组件通过 Docusaurus 的主题扩展注册为全局 MDX 组件MDXComponents.js 将AvailableFrom连同MinNodeVersion、MinBunVersion、MinEslintVersion等一并导出因此任意.mdx文档都可直接使用AvailableFrom v... /无需 import。仓库中大量文档页面如packages/docs/docs/animatedimage.mdx、packages/docs/docs/bundle.mdx等都在用它。理解了组件的渲染语义后就能明白版本取值为什么重要v的值会被直接拼进 Release 链接。如果填了一个尚未发布的版本号链接指向一个不存在的 tag如果填了main上已发布的旧版本号则会误导读者以为该功能是旧版本就有的。二、为什么是main版本 0.0.1Remotion 的版本模型要理解 update-version 技能的计算规则main的VERSION加 1 个补丁位需要先看清 Remotion 仓库的版本管理链条1. 版本号的唯一事实来源是packages/core/src/version.ts。该文件内容非常短见 version.ts// Automatically generated on publish export const VERSION 4.0.520;文件头部注释 Automatically generated on publish 说明它不是手工维护的——每次发布时由脚本重新生成。2. 生成逻辑在packages/core/ensure-correct-version.ts。ensure-correct-version.ts 会读取packages/core/package.json中的version字段重新写出src/version.ts然后执行构建bun run make与类型检查并校验dist/esm/version.mjs、dist/cjs/version.js两份产物中都确实包含了新版本号任何一个缺失都会process.exit(1)。这保证了package.json、源码常量、构建产物三处版本严格一致。3. 发布时由根目录set-version.ts统一抬升所有包。set-version.ts 是发布脚本用法bun set-version.mjs 4.0.178它要求当前在main分支上遍历packages/下所有含package.json的目录外加cloudrun/container把每个应发布包的version写成新版本随后依次触发 core 与 media-parser 的ensure-correct-version.ts校验、全仓库构建、packages/it-tests的版本一致性测试最后git add .提交一个vversion的 commit 并打 tag。4. 补丁版本递增是 Remotion 的既定发布节奏。仓库中另一份配套技能 version/SKILL.md 明确了这一前提We are working on the next version of Remotion. The current version can be found inpackages/core/src/version.ts.The next version is going to be a patch version.Ensure the docs correctly reference the next version.即main上的VERSION是最近一次已发布的版本下一个版本一定是 patch 1。update-version 技能正是在这个前提下工作的——文档 PR 中新增的AvailableFrom应该指向即将包含这些改动的那次发布也就是main版本 0.0.1。三、操作流程五步完成 PR 中AvailableFrom的版本更新以下流程完整继承自 update-version/SKILL.md适用于PR 包含packages/docs下的文档改动其中带有AvailableFrom v...且取值应反映下一个发布版本的场景。步骤 1获取main分支的规范版本号git fetch origin main --quiet git --no-pager show origin/main:packages/core/src/version.ts从输出中读出VERSION常量例如4.0.468然后把 patch 位加 1得到下一个补丁版本4.0.469。两点细节值得注意使用git show origin/main:...直接读取远端main的文件内容而不是读本地工作区——你的 PR 分支可能落后于main本地文件可能过期必须以远端为准只读取、不修改version.ts它由发布流程set-version.ts→ensure-correct-version.ts自动维护文档 PR 不应触碰。步骤 2定位当前 PR 改动的AvailableFrom条目git --no-pager diff origin/main...HEAD -- packages/docs | rg AvailableFrom v这条命令有三个精确约束缺一不可origin/main...HEAD三点 diff 只统计本 PR 相对main的分叉点引入的改动排除main上其他 PR 的变化-- packages/docs把范围限定在文档目录AvailableFrom只出现在文档源码中rg AvailableFrom v只保留含版本标注的行快速得到待核对清单含文件路径与行上下文。步骤 3只更新本 PR 触及的AvailableFrom取值将步骤 2 中列出的条目其v属性统一改为步骤 1 计算出的下一个补丁版本如4.0.469。写法上v4.0.469与vv4.0.469均可——从 AvailableFrom.tsx 的源码看组件会自动剥离v前缀。步骤 4不要改动 PR diff 之外的AvailableFrom这是技能文档中明确写出的红线全仓库有成百上千处AvailableFrom标注仅packages/docs/docs下的.mdx就有大量命中其中绝大多数对应的是早已发布的历史功能。它们的v值是该功能首次可用版本的准确记录与当前发布版本无关。只改本 PR diff 中的条目可以避免一次 PR 引入与主题无关的海量文档噪音也让 diff 评审聚焦于本次改动。步骤 5提交并推送将更新后的文档改动 commit 并 push 到当前 PR 分支。至此PR 中新增功能标注的版本号就与下一个实际会发布的版本号对齐了等main合入、执行bun set-version.ts version发布时main上的VERSION正好推进到该值文档标注随即变为已发布版本Release 链接也真实可达。四、与发布脚本的联动版本推进的完整闭环把 update-version 技能放回整个发布链路中看它其实是文档侧的一次预对齐文档 PR 阶段AvailableFrom标注为main版本 0.0.1本文流程合入main后正式发布时由 set-version.ts 把所有包的package.json抬升到同一新版本例如4.0.469它内部会跳过 featured 模板目录、按shouldReleasePackage策略过滤不需要发布的包策略来自packages/studio-shared/src/release-package-policy随后调用ensure-correct-version.ts重建version.ts并校验产物set-version.ts末尾还会git add . git commit -m vversion并打 tag——AvailableFrom组件指向的正是这类vversiontag形成文档徽标 → Release tag的闭环。换句话说如果文档 PR 把AvailableFrom写成了main上的旧版本号发布完成后该徽标会指向一个早于功能实际可用的 Release语义错误且难以追溯如果写成更大的未来版本Release 链接在发布时点又暂时 404。main 0.0.1 恰好是两边都不出错的唯一取值。五、实践要点小结唯一事实来源packages/core/src/version.ts的VERSION常量由 ensure-correct-version.ts 在发布时自动生成不要手工编辑它取值公式下一个补丁版本 main的VERSIONpatch 位 1前提是 Remotion 当前按 patch 节奏迭代见 .agents/skills/version/SKILL.md改动边界只改git diff origin/main...HEAD -- packages/docs命中的AvailableFrom v...其余条目一律不动格式容错v前缀可加可不加组件源码会自动剥离v为空会在渲染/构建时抛错渲染语义v值会直接拼进 GitHub Release 链接见 AvailableFrom.tsx 中href的构造所以取值必须对应一个真实存在的版本。这套流程把文档标注与版本发布两个本来异步的动作精确对齐文档 PR 提前把版本号预置到下一个补丁版本发布脚本随后把版本号推到同一值最终读者在文档中看到的版本徽标与 Release tag 严格一一对应。【免费下载链接】remotion Make videos programmatically with React项目地址: https://gitcode.com/GitHub_Trending/re/remotion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考