Builder.js Gen1 SDK 发布流程详解:@builder.io/react 与 @builder.io/sdk 的 npm 版本发布实战

发布时间:2026/9/16 19:51:55
Builder.js Gen1 SDK 发布流程详解:@builder.io/react 与 @builder.io/sdk 的 npm 版本发布实战 Builder.js Gen1 SDK 发布流程详解builder.io/react 与 builder.io/sdk 的 npm 版本发布实战【免费下载链接】builderVisual Development for React, Vue, Svelte, Qwik, and more项目地址: https://gitcode.com/GitHub_Trending/bu/builder本篇指南以 packages/react/PUBLISHING.md 为主线完整还原 Builder 可视化编辑平台builderGen1 React SDK 的版本发布流程从 npm 认证、CHANGELOG 维护到依次发布核心包builder.io/sdkpackages/core与 React 包builder.io/reactpackages/react。读完本文你将掌握两个互相依赖的 workspace 包的完整发布命令、每一步底层实际执行的操作构建产物、版本号替换、依赖版本同步以及.npmrc、.npmignore等发布相关配置的作用可直接按步骤复现一次真实的发布。两个包、一条发布链流程涉及的对象发布流程涉及仓库中的两个核心包它们通过 Yarn 3 workspaces 组织在一起见根目录 package.json 的workspaces与packageManager: yarn3.6.1配置包名所在目录说明builder.io/sdkpackages/core核心 SDK提供内容获取、组件注册Builder.register、视觉编辑器通信等基础能力builder.io/reactpackages/reactReact 集成包依赖builder.io/sdk提供BuilderComponent等 React 组件两者存在明确的依赖关系packages/react/package.json 中dependencies声明了builder.io/sdk: workspace:*通过workspace:*在 monorepo 内部引用发布时解析为具体版本。这也解释了原文档为什么规定发布顺序是先 Core、后 React——React 包构建时需要引用 Core 包的构建产物。当前仓库中的版本基线可作为示例参考builder.io/react为 9.4.6packages/react/package.jsonbuilder.io/sdk为 6.3.3packages/core/package.json。前置准备完成 npm 发布认证发布第一步是确认拥有向 npm原文档写作yarn npm即通过 Yarn 转发 npm 登录发布包的身份凭证。原文档给出的操作为yarn npm login按终端提示完成用户名、密码、邮箱输入后即可。这一步是后续所有publish命令的前提认证失败时发布会在最后一步报错。第 1 步更新 CHANGELOG.md原文档要求在发布前根据改动落在哪个包更新 packages/core/CHANGELOG.md 和/或 packages/react/CHANGELOG.md。从两个 CHANGELOG 的实际格式看仓库采用的是 Changesets 风格的结构化日志每个版本一个## x.y.z二级标题下面按### Major/Minor/Patch Changes分节每条改动前缀提交短哈希如08321f6:并附文字描述。例如 packages/react/CHANGELOG.md 中 9.4.4 版本就记录了一次纯依赖联动发布## 9.4.4 ### Patch Changes - Updated dependencies [c8f3d4a] - builder.io/sdk6.3.3这个例子值得注意当只有builder.io/sdk发生变化时React 包的 CHANGELOG 也会生成一条 Updated dependencies 记录说明依赖包版本升级同样需要在下游包的日志中体现。仓库根目录 devDependencies 中引入了changesets/cli见根 package.json并提供g:changeset脚本用于生成变更集与上述日志格式相互印证。第 2 步发布 Corebuilder.io/sdk原文档指示在packages/core目录下运行yarn run release:patch或release:minor、release:major。对照 packages/core/package.json 中的脚本定义这三个命令的实际展开是# release:patch yarn run build yarn version patch yarn npm publish # release:minor yarn run build yarn version minor yarn npm publish # release yarn run build yarn npm publish其中build脚本为yarn run tsc rollup -c yarn set-sdk-version即整条发布链实际执行四段操作yarn run tsc用tsc --module commonjs编译 TypeScript 并生成类型声明rollup -c执行 packages/core/rollup.config.js产出dist/index.cjs.js、dist/index.esm.js、dist/index.browser.js等多种模块格式产物对应 package.json 的main/module/unpkg入口yarn version patch/minor/major由 Yarn/npm 的 version 命令将package.json中的版本号按语义化版本递增yarn npm publish将包发布到 npm registry。版本号注入机制set-sdk-version 脚本构建产物中有一个关键细节核心 SDK 需要把自己的版本号报告给 Builder 视觉编辑器。这个动作由 packages/core/scripts/set-sdk-version.sh 完成脚本逻辑如下# 从 package.json 读取当前版本号 VERSION$(grep -o version: *[^]* package.json | sed s/version: \(.*)\)/\1/) # 在 dist 所有文件中把占位符替换为真实版本 find dist -type f -exec sed -i.bak s/UNKNOWN_VERSION_TO_REPLACE/$VERSION/g {} 源码中的版本位置在构建时写死为UNKNOWN_VERSION_TO_REPLACE占位符这正是它必须在yarn version之后执行的原因——先升版本号再把版本号替换进产物替换完成后删除所有.bak临时文件。脚本开头还做了目录校验只有从packages/core目录本身运行时才继续否则打印错误并退出防止误操作其他包。发布包的取舍.npmignore 与 .npmrcpackages/core/.npmignore 排除了/index.ts、/index.js、*.log、/src、.rpt2_cache——即 npm 包里只保留dist/构建产物与 package.json 等元信息不发布源码仓库中两个包目录下的.npmrc配置git-tag-versionfalseYarn 3 下yarn version不会额外创建 git tag与npmPublishAccess: public以公共包身份发布不要求 Pro 账号。第 3 步发布 Reactbuilder.io/react原文档指示在packages/react目录下运行yarn run release:patch或release:minor、release:major。对照 packages/react/package.json 的scripts段完整的发布相关命令族如下比原文档列出的三项更完整# 常规三个版本级别构建 升版本 发布 release:patch: yarn build yarn version patch yarn npm publish release:minor: yarn build yarn version minor yarn npm publish release:major: yarn build yarn version major yarn npm publish # 不升版本仅重新构建发布当前版本 release: yarn build npm publish # 预发布通道 release:nightly: yarn build yarn version prerelease yarn npm publish --tag nightly release:dev: yarn version prerelease yarn pack tar -zxvf package.tgz \ cp package/package.json ./package.json rm -rf package package.tgz \ yarn build yarn npm publish --tag dev其中release:dev的写法比较特殊先用yarn pack打出 tarball再把其中已升好版本号的 package.json 拷回然后重新构建并以--tag dev发布——这是一条面向开发验证的预发布通道不影响latesttag。React 包的构建产物构成build脚本为rimraf dist NODE_ENVproduction tsc --module commonjs rollup -c rollup.config.ts yarn set-sdk-version。Rollup 配置 packages/react/rollup.config.ts 定义了四组输出与 package.json 中的入口字段一一对应产物文件格式对应字段用途dist/builder-react.browser.jsUMD—浏览器全局构建全局名BuilderReactdist/builder-react.es5.jsESmodule打包器消费dist/builder-react.cjs.jsCJSmainNode/CommonJS 消费dist/builder-react.unpkg.jsIIFEunpkgCDN 直链引入dist/builder-react-lite.{esm,cjs}.jsES/CJSlite.js轻量版入口其中 Lite 构建入口为src/builder-react-lite.ts是一个值得一提的发布产物lite.js 的头注释说明用户可以把导入路径换成builder.io/react/lite然后按需单独 import 内置块组件如builder.io/react/dist/lib/src/blocks/Button配合Builder.register(editor.settings, { customInsertMenu: true })实现编辑器菜单只展示已导入组件的按需加载场景。external 的处理也值得注意主构建会把dependencies、optionalDependencies、peerDependencies全部排除在 bundle 之外peerDependencies为react 16.8.0 || ^19.0.0-rc与react-dom而isolated-vm因体积与平台特性被显式写入external保证发布的产物不包含这些依赖本体。React 包同样有 scripts/set-sdk-version.sh逻辑与 Core 版本一致替换dist内UNKNOWN_VERSION_TO_REPLACE占位符且要求必须从packages/react目录运行。这与build脚本中先tsc、再rollup、最后set-sdk-version的顺序完全吻合。版本联动脚本 fix-core-version除了文档列出的三步packages/react还有一个版本同步脚本 scripts/fix-core-version.sh由fix-core-version命令调用VERSION_NUMBER$(jq -r .version ../core/package.json) jq --arg VERSION_NUMBER $VERSION_NUMBER \ .dependencies.builder.io/sdk $VERSION_NUMBER package.json temp.json mv temp.json package.json它从packages/core/package.json读取 Core 的最新版本号写回 React 包package.json的builder.io/sdk依赖声明。脚本注释说明这是对 changesets 一个已知行为issue #432的 workaround——即当 Core 版本升级后用它保证 React 包声明的 SDK 版本与实际发布的 Core 版本严格一致。这进一步印证了先发布 Core、再发布 React的顺序约束若反过来操作React 包声明的 SDK 版本将不存在于 registry 上。发布前的质量门槛发布之外仓库为 React 包定义了生产级测试命令test:prodyarn lint yarn test -- --coverage --no-cache见 packages/react/package.json 与 jest.config.js测试用例位于 packages/react/test 目录。从 packages/react/.travis.yml 的历史 CI 配置看构建与测试是发布前的标准校验环节实际执行发布前建议先跑yarn test:prod确认 lint 与单测全部通过。完整操作清单可直接照做结合原文档步骤与仓库脚本实际内容一次完整发布的操作序列为# 0. 认证首次 yarn npm login # 1. 更新 CHANGELOG.md改动在 core 就改 core 的改动在 react 就改 react 的 # 参考 packages/core/CHANGELOG.md 与 packages/react/CHANGELOG.md 的既有格式 # 2. 发布 Core cd packages/core yarn run release:patch # 或 release:minor / release:major # 3. 发布 React cd packages/react yarn run release:patch # 或 release:minor / release:major # 如 Core 刚升过版本且 React 包依赖声明需同步可先执行 yarn fix-core-version每步release:*命令内部均包含清理旧dist→ 编译 → Rollup 多格式打包 → 版本号递增 → 占位版本注入 → 发布的完整链路因此无需手动拆分执行但一旦中途失败需注意yarn version已修改package.json版本而产物尚未发布应重新运行完整release:*命令保证构建与版本号一致。小结发布对象是两个 monorepo 内的 workspace 包顺序为builder.io/sdkpackages/core→builder.io/reactpackages/react顺序由 React 对 SDK 的workspace:*依赖决定release:patch/minor/major是构建 版本递增 发布的原子组合额外还有release不升版重发、release:nightly、release:dev三条辅助通道UNKNOWN_VERSION_TO_REPLACE占位符 set-sdk-version.sh的构建后替换是保证发布产物内嵌版本号正确且与 package.json 一致的机制.npmrcgit-tag-versionfalse、npmPublishAccess: public与.npmignore只发布dist产物共同约束了发布的包内容与身份理解这两份小文件有助于排查发布产物里缺文件或版本 tag 缺失类问题。【免费下载链接】builderVisual Development for React, Vue, Svelte, Qwik, and more项目地址: https://gitcode.com/GitHub_Trending/bu/builder创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询