学习Vue2的发布流程：原来大厂是这么发布项目的！

前端工作日常
74 阅读3分钟

你是否好奇像Vue这样的明星开源项目是如何发布新版本的？今天我们就通过Vue2的发布脚本，揭秘大厂级别的发布流程！整个过程就像一条精密的流水线，每个环节都环环相扣。

🎯 第一步：确定版本号（贴标签）

if [[ -z $1 ]]; then
  echo "Enter new version: "
  read -r VERSION
else
  VERSION=$1
fi
  • $1：表示脚本接收的第一个参数。比如执行 ./release.sh 2.7.0，那么 $1 就是 "2.7.0"
  • -z：判断字符串是否为空的检测器。-z $1 意思是"如果 $1 是空字符串"
  • [[ ]] ：Bash 的增强版条件判断符号（比传统的 [ ] 更强大安全）
  • 整体含义：检查用户是否在运行脚本时输入了版本号参数
    → 如果没输入（$1 为空），就进入交互模式要求用户输入
    → 如果已输入（如 ./release.sh 2.7.0），就直接使用该版本号

这就像给新产品贴标签。脚本先检查是否通过命令参数传入了版本号（如./release.sh 2.7.0），如果没有就提示你手动输入。目的是确保每个版本都有明确的身份标识。

🛑 第二步：二次确认（安全闸）

read -p "Releasing $VERSION - are you sure? (y/n) " -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]; then
  • read：Bash 的内置命令，用于读取用户输入
  • -p：显示提示文本（prompt），这里显示 "Releasing xxx - are you sure? (y/n)"
  • -n 1：只需读取1个字符（用户按单个键就继续，不用按回车）
  • -r：禁用反斜杠转义（防止特殊字符被误解）
  • REPLY：内置变量，自动保存用户输入的内容

这里会弹出一个确认提示，必须输入y才能继续。为什么需要这个？ 就像火箭发射前的"确认按钮"，防止误操作导致事故性发布！

🧪 第三步：质量检测线（全自动质检）

npm run lint              # 代码风格检查
npm run flow              # 类型检查
npm run test:cover        # 单元测试
npm run test:e2e          # 端到端测试
npm run test:ssr          # 服务端渲染测试

这部分是最重要的质量关卡，相当于产品出厂前的全面质检：

  • 代码风格检查：确保代码整洁统一
  • 类型检查：提前发现潜在类型错误
  • 测试覆盖率：验证测试完整性
  • 多种环境测试：覆盖不同使用场景

🏗️ 第四步：生产打包（产品组装）

VERSION=$VERSION npm run build
  • 在执行 npm run build 之前，创建一个临时环境变量 VERSION，其值为脚本中的 $VERSION 变量值。构建工具可通过 process.env.VERSION 获取到传入的版本号
  • 这里运行构建命令生成最终的生产环境文件，存放在dist/目录。关键点是传入版本号，确保生成的文件包含正确的版本信息。

📦 第五步：子组件发布（协同作战）

(cd packages/vue-template-compiler
 npm version "$VERSION"
 npm publish
)

(cd packages/vue-server-renderer
 npm version "$VERSION"
 npm publish
)

npm version "$VERSION" 做了三件重要事情：

  1. 更新 package.json：把文件中的 "version" 字段改为新版本号（如 "2.7.0"）
  2. 创建 Git 提交：自动生成一条 commit 信息（默认是版本号，可用 --message 自定义）
  3. 打 Git 标签：创建一个名为 v版本号 的标签（如 v2.7.0）
# 手动实现等价操作
sed -i 's/"version":.*/"version": "2.7.0"/' package.json  # 改版本号
git add package.json
git commit -m "2.7.0"  # 自动生成的提交
git tag v2.7.0 -m "2.7.0"  # 创建标签

具体效果：

  1. 创建永久快照：标记代码在 2.7.0 版本时的完整状态
  2. 生成版本锚点：可通过 git checkout v2.7.0 随时切回此版本
  3. 形成发布里程碑：在 GitHub 等平台会自动识别为可发布版本

为什么需要标签？

  • 当用户执行 npm install vue@2.7.0 时
    → npm 实际是根据 Git 标签找到对应代码
    → 下载标签时刻的代码快照
    → 确保每次安装的版本完全一致

Vue2由多个子包组成，这步就像流水线上的分装车间：

  1. 分别进入编译器(vue-template-compiler)和SSR渲染器(vue-server-renderer)目录
  2. 更新它们的package.json版本号
  3. 独立发布到npm 为什么重要？ 确保所有关联包版本一致，避免兼容性问题！

🔖 第六步：版本快照（存档记录）

git add -f dist/*.js      # 强制添加构建产物
git commit -m "build: build $VERSION"
npm version "$VERSION" --message "build: release $VERSION"

这里做三件关键事：

  1. 强制将构建产物加入Git（通常这些文件会被忽略）
  2. 创建版本提交
  3. 使用npm version打上标签（如v2.7.0） 目的：精确记录每个版本的完整状态，方便回溯。

🚀 第七步：最终发布（上架销售）

git push origin refs/tags/v"$VERSION"  # 推送标签
git push                                # 推送代码
npm publish                             # 发布主包

最后一步的三连击：

  1. 将版本标签推送到远程仓库
  2. 推送代码更新
  3. 发布主Vue包到npm 至此，新版本正式上线！

💡 流程设计的精妙之处

  1. 安全第一：双重确认 + 自动终止（set -e）
  2. 质量优先：测试套件全覆盖，拒绝"带病发布"
  3. 原子操作：子包独立发布，互不影响
  4. 版本同步：主包和子包版本严格一致
  5. 灵活扩展：通过环境变量控制流程（如跳过测试）

✨ 我们能学到什么？

即使你不开发框架，这套流程的思想也值得借鉴：

  1. 重要操作前加确认，防止手误
  2. 自动化测试是质量的基石
  3. 版本管理要规范清晰
  4. 复杂操作脚本化，避免人为失误

Vue的发布流程就像精心设计的瑞士手表，每个齿轮都精准咬合。理解了这套机制，下次执行npm update vue时，你会对背后的工程智慧会心一笑！

avatar
文章
阅读
粉丝