后端MCP 服务MCP ClientsAI Agent人工智能【免费下载链接】mcp-useThe fullstack MCP framework to develop MCP Apps for ChatGPT / Claude MCP Servers for AI Agents.项目地址https://gitcode.com/gh_mirrors/mc/mcp-use点击查看免费下载本指南围绕 mcp-use 仓库libraries/typescript/.changeset/README.md及配套的 CI 工作流系统讲解 TypeScript 多包仓库如何使用 Changesets 完成版本管理与发布包括创建 changeset 的正确姿势、main 分支稳定版与 canary 分支预发布两条自动化流水线、.changeset/config.json关键配置的含义以及哪些命令必须交给 CI、哪些命令需要人工执行。读完本文你将能独立为一个 mcp-use TypeScript 包提交合规的变更描述并理解一次发布从 PR 合并到 npm 发布、Git tag 与 GitHub Release 创建的全过程。为什么 mcp-use 需要 Changesetsmcp-use 的 TypeScript 侧是一个标准的多包monorepo工程根目录位于 libraries/typescript通过 pnpm-workspace.yaml 声明了packages/*及若干嵌套示例目录。仓库内同时存在多个需要独立发版的 npm 包包括但不限于mcp-use、mcp-use/client、mcp-use/server、mcp-use/agent、mcp-use/cli、mcp-use/inspector、mcp-use/tunnel和脚手架create-mcp-use-app可参见 package.json 中的workspaces配置与发布脚本。多包仓库面临两个核心问题变更归属不明确一次提交可能同时改动多个包人工判断这次该给谁升版本容易出错变更记录丢失PR 合并后changelog 往往靠事后补写版本历史与代码变更脱节。Changesetschangesets/cli已在根devDependencies中声明正是为解决这些问题而生的工具它在提交代码时就记录哪个包、哪种升级类型、改了什么版本号与 changelog 由工具统一计算生成保证发布信息与代码变更强绑定。协作铁律所有 TypeScript 变更必须附带 changeset在 mcp-use 仓库中提交 changeset 不是可选项而是强制要求。项目根目录的 CONTRIBUTING.md 明确写道All TypeScript changes require a changesetdescribing what changed. This is enforced in CI for PRs tomain.即任何改动 TypeScript 包的 PR都必须同时提交一个描述变更的 changeset 文件并且该要求在合并到main的 PR 上由 CI 强制校验CI 检查清单中的 Changeset verification (PRs to main only) 即对应 ci.yml 中的相关步骤。因此创建 changeset 是每一位贡献者提交 TypeScript 代码前的必备动作。快速上手用pnpm changeset创建变更记录在仓库根目录执行cd libraries/typescript pnpm changeset命令会以交互式问答引导你完成三步选择哪些包发生了变更Select which packages have changes选择版本升级类型Choose the version bump typemajor/minor/patch对应语义化版本规则编写变更摘要Write a summary of the changes一段描述本次改动的文本。完成后工具会在libraries/typescript/.changeset/目录下生成一个类似tidy-melons-sing.md的 Markdown 文件其内部结构为 YAML frontmatter 加正文摘要--- mcp-use/client: patch mcp-use: minor --- 为客户端新增对某某传输协议的支持并修正了连接超时时的错误提示。frontmatter 中列出受影响的包名与对应的 bump 类型正文则是会进入 changelog 的描述文本。提交并推送 changeset 文件与代码改动放在同一个提交中git add . git commit -m feat: your feature description git push提示建议遵守项目的 conventional commit 约定见 CONTRIBUTING.md例如feat(typescript): ...、fix(typescript): ...便于维护者快速定位变更性质。自动化发布哪些命令不能手动执行Changesets 的完整工作流包含两个阶段收集变更创建 changeset与应用变更版本计算 发布。在 mcp-use 中后一阶段被 GitHub Actions 完全接管pnpm version由 CI 自动处理禁止手动执行即版本号提升与 changelog 生成pnpm release由 CI 自动处理禁止手动执行即发布到 npm。也就是说贡献者的职责只到创建 changeset 并推送为止之后的版本计算、CHANGELOG 更新、npm 发布全部交给流水线。这与根 package.json 中脚本的设计一致——version和release脚本虽然存在但被设计为仅供 CI 内部调用version会执行自定义的 version-packages.mjs内部通过spawnSync调用changeset二进制并处理 workspace 依赖传播release则执行pnpm build changeset publish。脚本可用但不意味着应人工触发。main 分支稳定版发布流程向main分支合入变更时流程如下贡献者执行pnpm changeset创建 changeset通过 PR 推送到mainCI 自动创建一份 Version Packages PR该 PR 内会应用版本计算、更新各包 CHANGELOG.md 与 workspace 依赖元数据并刷新 lockfile合并该 Version PR 后流水线自动将稳定版发布到 npm并附带打 Git tag、创建 GitHub Release。canary 分支预发布流程canary 分支走预发布prerelease通道用于在正式发版前验证新功能同样先pnpm changeset创建变更记录推送到canary分支CI 自动以x.y.z-canary.N形式发布预发布版本pre.json与changeset pre enter canary机制由 typescript-release.yml 管理。流水线源码解读一次发布在 CI 中经历了什么真正的发布逻辑集中在 .github/workflows/typescript-release.yml。该工作流在main与canary两个分支上触发并只关注libraries/typescript/**与工作流自身的变化。其关键步骤可以概括为一条清晰的链路构建与自检pnpm install --frozen-lockfile→pnpm build→pnpm verify:release-install验证打包产物可被正常安装防止能编译但装不上的问题。canary 分支进入预发布模式若.changeset/pre.json不存在则执行pnpm changeset pre enter canary并提交该文件。检查待发布 changesets通过pnpm release-channel pending判断是否有待应用的变更没有则直接跳过发布。生成并校验发布计划pnpm release-channel prepare/preflight/validate结合changeset status输出确保发布计划合法。应用版本pnpm changeset version写入新版本号并更新 changelog随后刷新 lockfile 并提交。发布pnpm changeset publish使用 npm 的 trusted publishingOIDC机制无需手动配置 npm token。验证与打标pnpm release-channel verify校验已发布的版本与 dist-tag随后pnpm changeset tag推送 Git tag。创建 GitHub Release从各包 CHANGELOG.md 中提取对应版本段落作为 Release 正文mcp-use主包在稳定发布时会被标记为latest。下游联动main 稳定发布后还会生成部署标记.railway-deploy-marker供 Railway 等部署流水线消费canary 分支会被强制 reset 回 main保持预发布通道始终与最新稳定代码对齐。从这条链路可以看出mcp-use 的发布流水线在标准changeset versionchangeset publish之外还叠加了release-channel系列脚本见 package.json 中的release-channel、version:check等命令做发布计划的预演与校验属于对 Changesets 能力的工程化封装。.changeset/config.json配置逐项解读mcp-use 的 changeset 配置 内容如下{ $schema: https://unpkg.com/changesets/config3.1.1/schema.json, changelog: changesets/cli/changelog, commit: false, fixed: [], linked: [], access: public, baseBranch: main, updateInternalDependencies: patch, ignore: [], ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH: { onlyUpdatePeerDependentsWhenOutOfRange: true } }各字段在 mcp-use 场景下的含义配置项值说明changelogchangesets/cli/changelog使用 CLI 自带的 changelog 生成器changeset 正文摘要会被自动写入各包CHANGELOG.mdcommitfalsechangeset 不自动代为创建 git 提交提交行为由 CI 工作流中的显式git commit控制fixed/linked[]未把任何包做版本联动或版本锁定各包独立计算版本accesspublic发布到公共 npm registry这也是 CI 中使用 trusted publishing 发布的前提baseBranchmain版本计算与 PR 比较以main为基准分支与发布工作流的触发分支一致updateInternalDependenciespatchworkspace 内部依赖版本更新策略依赖方最低以patch级别跟随被依赖包的版本变化ignore[]没有包被排除在版本管理之外___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.onlyUpdatePeerDependentsWhenOutOfRangetrue仅当 peer 依赖范围不满足时才联动更新 peer 依赖方减少不必要的连带版本变更注意baseBranch: main与 typescript-release.yml 中针对main、canary两个分支的分支逻辑共同构成完整发布模型——配置声明基准工作流声明通道。配套工程能力dependabot 依赖升级的自动 changeset多包仓库中依赖升级是最频繁的变更来源之一。为此仓库还提供了 .github/workflows/dependabot-changesets.yml当 Dependabot 提交的 PR 修改了libraries/typescript/**/package.json时该工作流会自动分析 PR 相对origin/main的 diff找出受影响且非private的公开包解析依赖版本变化生成形如mcp-use/client: patch的 changeset将 changeset 提交并推送回 Dependabot 分支。这一机制保证了依赖升级必须带 changeset的规则对机器人同样生效从源头避免 CI 的 changeset 校验失败。该工作流同时支持workflow_dispatch手动触发可指定 PR 号与force参数用于强制重新生成。常见操作与排错查看当前是否有待发布的 changeset / 版本状态cd libraries/typescript pnpm version:check # 等价于 changeset status如果输出提示存在未应用的 changeset说明有变更记录待版本计算等待 CI 的 Version PR 或 canary 发布即可。我提交了代码但 CI 报 changeset 校验失败说明改动涉及 TypeScript 包却未附带.changeset/*.md文件。回到 快速上手 一节执行pnpm changeset生成记录后随代码一起提交。PR 中意外提交了多个 changeset.changeset/目录下允许存在多个.md文件CI 会一次性消费全部待处理 changeset若需要清理删除多余的 changeset 文件并保持至少一个有效记录即可不要手动改动版本号。小结围绕libraries/typescript/.changeset/README.md约定mcp-use 的 TypeScript 发布体系可以概括为三句话贡献者只负责一件事为 TypeScript 变更创建并提交 changesetpnpm changeset这是 CI 强制要求的唯一人工环节版本与发布完全自动化pnpm version/pnpm release由 typescript-release.yml 接管main 出稳定版、canary 出-canary.N预发布版并自动完成 changelog、Git tag、GitHub Release 与部署标记的全链路工具链在标准之上做了工程化增强release-channel预演校验、verify-release-install安装自检、dependabot 自动 changeset 等机制都是为了降低多包发布中的人为失误率。这套流程同样适用于其他基于 Changesets 的多包 TypeScript 仓库——理解.changeset/config.json的语义、厘清收集变更与应用变更的职责边界是驾驭任何 changesets 工程的第一步。赞分享后端MCP 服务MCP ClientsAI Agent人工智能【免费下载链接】mcp-useThe fullstack MCP framework to develop MCP Apps for ChatGPT / Claude MCP Servers for AI Agents.项目地址https://gitcode.com/gh_mirrors/mc/mcp-use点击查看免费下载相关推荐esp-hal AES加密保护敏感数据的实用方法esp hal AES加密保护敏感数据的实用方法 在物联网和嵌入式开发中数据安全至关重要。esp hal提供了高效的AES硬件加速功能帮助开发者轻松实现数嵌入式驱动开发硬件开发物联网Task Master 仓库中的 Changesets 版本管理与发布流程实战指南Task Master 仓库中的 Changesets 版本管理与发布流程实战指南 Task Master 是一个面向 AI 驱动开发的任务管理系统支持 CuAI Agent开发工具CLIMCPnodejs.org 仓库的 Changesets 发布流程从编写 changeset 文件到自动发布 npm 包nodejs.org 仓库的 Changesets 发布流程从编写 changeset 文件到自动发布 npm 包 nodejs.org 是一个 pnpm m前端文档上一篇国家中小学智慧教育平台电子课本下载终极指南三步轻松获取PDF教材的完整解决方案下一篇gh_mirrors/es/es6features实战对象属性遍历方法对比创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
