工程化 on Saiga

写几个小脚本帮自己省时间：前端 CLI / 脚手架实践

wuwenzen@outlook.com (wuwj) — Sat, 28 Sep 2024 00:00:00 +0000

有段时间我发现自己经常在做几件很机械的事：

新建一个页面：建目录、复制模板、改标题、改路由
加一个接口：建 service 文件、写类型、写请求封装
搭一个模块：列表页 + 详情页 + 编辑页，一遍遍重复

于是索性写了一组小 CLI 工具，把这些动作变成命令行：

npx fe-tools create-page
npx fe-tools create-api
npx fe-tools create-module

这篇文章就简单记录一下这几个脚本的思路。

1. `create-page`：新页面一条命令

很多中台项目新增页面的套路都差不多：

在 views 下建目录
填一个基础骨架组件
在路由里挂载
有的还要加到菜单配置里

用 Node.js 写了一个 create-page 命令：

npx fe-tools create-page

命令执行后，做几件事：

命令行交互询问：
- 页面英文名（路由 path）
- 页面中文标题
- 页面类型：列表 / 表单 / 详情 / 组合
基于模板生成对应文件，例如：

<template>
  <PageWrapper title="投资人概览">
    <!-- TODO: 填充页面内容 -->
  </PageWrapper>
</template>

<script setup lang="ts">
// 预留接口调用和状态管理位置
</script>

自动往某个路由模块里追加配置

这样新页面出现的那一刻就已经可以访问，只需要填内容。

2. `create-api`：接口封装生成器

写接口封装时经常要做：

把多个前端项目合进一个 Monorepo 是怎样的体验

wuwenzen@outlook.com (wuwj) — Sun, 15 Jan 2023 00:00:00 +0000

之前团队的前端项目是这样管理的：

每个系统一个 Git 仓库；
各自有一套构建脚本、一份依赖清单；
公共组件、工具要么复制粘贴，要么用「半私有」的 NPM 包。

结果就是：

组件 bug 修一份，要手动同步 N 个仓库；
依赖升级经常有「版本错乱」；
CI 流水线一堆重复配置。

于是我们决定把几个核心前端项目合到一个 Monorepo 里。
这篇文章就是那次迁移的实战记录：工具选择、包划分、依赖管理、CI 改造，全流程。

1. 为什么要搞 Monorepo？

总结下来就是三点：

公共代码复用
- 组件库、Hooks、工具函数不用再复制粘贴；
- bug 修一次，多项目同步升级。
一致的工程规范
- 统一 ESLint/Prettier/Commit 规范；
- 统一构建脚手架和发布流程。
协同开发体验好
- 打开一个仓库就能看到相关项目；
- 修改组件立刻能在多个应用里验证。

当然，Monorepo 不是银弹，仓库会变大、CI 要更精细。
所以「是否值得」的标准是：

项目之间有明显共享，且会长期共同演进。

2. 工具选型：pnpm + Turborepo

我们调研了一圈：Lerna、Nx、Yarn Workspaces、pnpm Workspace、Turborepo……
最后选的是：pnpm Workspace + Turborepo，原因：

pnpm：硬链接节省磁盘空间、依赖管理清晰、速度快；
Turborepo：任务编排 + 缓存好用，学习成本相对较低。

2.1 仓库结构

repo-root
├── apps
│   ├── manager-web        # 管理端
│   ├── investor-web       # 投资人 Web
│   └── mini-program       # 小程序（uni-app 等）
├── packages
│   ├── ui-components      # 通用 UI 组件库
│   ├── shared-utils       # 工具函数
│   └── eslint-config      # 统一 ESLint 配置
├── package.json
├── pnpm-workspace.yaml
└── turbo.json

pnpm-workspace.yaml：

给前端项目接上 CI/CD：自动构建与预发布环境

wuwenzen@outlook.com (wuwj) — Wed, 20 Oct 2021 00:00:00 +0000

以前做前端上线，经常是这样的：

本地 npm run build 打包；
用 FTP 或手动拷贝把 dist 丢到服务器；
出了问题再手动覆盖回去。

这种方式有几个明显缺点：

完全依赖人的操作习惯，出错难追踪；
没有固定的「预发布环境」，测试体验不好；
回滚麻烦，基本靠「手快」。

这篇文章记录的是：一次给前端项目接上 CI/CD 的实际过程，目标是：

提交代码 → 自动构建 → 部署到预发布 → 人工验证 → 一键上线 & 可快速回滚。

1. 流程目标先画出来

先不管用什么平台（GitHub Actions、GitLab CI、Jenkins…），流程大致分为几步：

CI 阶段（持续集成）
- 安装依赖；
- 跑 lint / 单测；
- 打包构建。
CD 阶段（持续交付/部署）
- 构建产物上传到制品库或对象存储；
- 自动部署到预发布环境；
- 人工验证无问题后，再部署到生产；
- 所有版本有记录，可一键回滚。

把这张「大图」先画给团队看，大家对齐预期后，再来谈具体实现。

2. 以 GitHub Actions 为例写一个最小流水线

2.1 基础 CI：安装 + 构建

.github/workflows/ci.yml：

name: Frontend CI

on:
  pull_request:
    branches: [ main, develop ]
  push:
    branches: [ develop ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Build
        run: npm run build

      - name: Archive production artifacts
        uses: actions/upload-artifact@v3
        with:
          name: dist
          path: dist

这样每次 PR / 推送到 develop，都能自动帮你检查：