前端向架构突围系列 - 工程化（五）：企业级脚手架的设计与落地

写在前面
很多团队都有一个“规范文档”，它通常静静地躺在 Wiki 的角落里，只有新员工入职的第一天会被打开，然后迅速被遗忘。
依靠文档约束人性的规范，注定是失败的。
在架构师的眼里，规范不应该是一个文档，而应该是一个产品——一个通过脚手架（CLI）和预设包（Presets）交付给开发者的“黑盒子”。开发者不需要知道 ESLint 的ecmaVersion是多少，也不需要纠结 Prettier 的semi是 true 还是 false，他们只需要打开盒子，直接开始工作。
本篇我们将探讨如何从“配置工程师”进化为“规范制定者”，通过工程化手段把标准“装进盒子里”，让错误根本无法发生。

一、 熵增定律：为什么 Copy-Paste 是万恶之源？
在没有脚手架体系的团队，新项目的建立通常源于一句：“你去把那个老项目的配置拷贝一份过来。”
这种“细胞分裂”式的工程创建方式，导致了严重的配置熵增：

1. 版本分裂：项目 A 用的是 ESLint v7，项目 B 拷贝过去后升级到了 v8，项目 C 又拷贝了 A... 最终团队维护着 5 个版本的 Lint 规则。
2. 规则漂移：张三觉得no-console很烦，在项目 B 里关掉了；李四觉得分号很丑，在项目 C 里去掉了。半年后，这两个项目的代码风格就像出自两个物种。
3. 基建升级灾难：当架构师决定“我们需要在所有项目里引入 Commitlint”时，他发现他需要修改 100 个仓库的package.json。这不仅是体力活，更是巨大的风险。

架构原则一：不要让开发者直接维护配置文件。配置文件应当作为依赖包被引入。

二、 核心策略：Configuration as Dependency
要解决上述问题，必须把配置从“项目内的文件”变成“npm 包”。
2.1 也就是 Shared Config
在 Monorepo 或 npm 私有库中，我们需要维护一套核心的规范包：

• @company/eslint-config-react
• @company/prettier-config
• @company/tsconfig

在业务项目中，.eslintrc.js应该只有一行代码：

module.exports = { extends: ['@company/eslint-config-react'] };

2.2 拥抱 ESLint Flat Config (Config System 的革命)
2024 年以后的架构设计，必须正视ESLint Flat Config (eslint.config.js)的存在。 旧的.eslintrc级联系统极其复杂，导致extends覆盖逻辑经常失效。Flat Config 将配置视为一个扁平的对象数组，使得配置的组合、覆盖和共享变得符合直觉（就像合并数组一样简单）。
架构师的职责，就是提前踩平 Flat Config 的坑，把它封装成一个开箱即用的 Plugin，屏蔽掉底层复杂的 Plugin 加载逻辑。

三、 门神：Husky 与 Git Hooks 的强制执行
有了规范包，怎么保证开发者一定会遵守？靠自觉是不够的，必须有**“暴力”拦截**。
3.1 提交时的最后一道防线
利用husky+lint-staged，我们实现了“增量检查”。 不要试图在 commit 时检查全量代码，那会让git commit慢得像npm install。只检查暂存区（Staged）的文件，是工程体验和代码质量的最佳平衡点。
3.2 Commit Message 的标准化
为什么提交信息也需要规范？ 如果你想做自动化发版（Automated Release）、自动生成 Changelog，那么 Commit Message 就必须符合Conventional Commits规范。

• feat: add login-> 触发 Minor 版本更新
• fix: bug in style-> 触发 Patch 版本更新

通过commitlint拦截乱写的提交信息，是通往自动化运维（DevOps）的必经之路。

四、 交付载体：脚手架（CLI）的架构设计
当规范包和 Lint 工具都准备好了，我们需要一个载体把它们送达给开发者。这就是CLI（Command Line Interface）。
4.1 现代脚手架的技术选型
别再用 Yeoman 了，也别只会git clone。现代脚手架（如create-vite,create-next-app）的架构已经非常成熟：

• 交互层：prompts(比 Inquirer 更轻量)
• 参数解析：cac(比 Commander 更现代)
• 模板引擎：实际上，现代趋势是去模板引擎化。直接拷贝预设好的文件夹结构（Template），然后修改个别文件（package.json name）。这种方式比 EJS 渲染更直观，维护成本更低。

4.2 Preset 模式 vs Generator 模式

• Generator 模式（重逻辑）：询问你“要不要 Router？”“要不要 Pinia？”，然后通过代码动态生成文件。维护成本高，容易出错。
• Preset 模式（重模板）：维护几个标准的模板仓库（Template Repo），CLI 的作用仅仅是下载对应模板。推荐架构：对于企业内部，Preset 模式更优。架构组维护template-react-admin、template-h5-activity等标准模板库，CLI 负责拉取和初始化。这实现了“模板与工具解耦”。

五、 落地与治理：从技术到政治
写出一个 CLI 很容易，让几百号人愿意用很难。这就是架构的政治属性。
5.1 存量治理的艺术
对于老项目，不要试图“一刀切”地加上最严格的 ESLint 规则。那会导致满屏红线，开发者的第一反应就是/* eslint-disable */或者直接卸载插件。
策略：提供lint-fix脚本，并引入"Warning First"策略。先将新规则设为 Warning，给团队 1-2 个迭代的缓冲期，再逐步收紧为 Error。
5.2 零配置（Zero-Config）的幻觉
大家都在吹捧“零配置”，但企业级架构不能零配置。 你需要暴露必要的扩展点（Hooks）。比如，脚手架生成的 Webpack 配置，必须允许业务项目通过chainWebpack或mergeConfig进行覆盖。架构师的智慧在于：提供完美的默认值，但保留修改的权利。

结语：标准化的终极形态
一个优秀的前端工程体系，应该让开发者感觉不到“规范”的存在。 当你git commit时，格式自动被格式化了；当你git push时，代码质量自动被检查了；当你初始化项目时，最佳实践已经自动就位了。
把标准装进盒子里，把自由还给开发者。
Next Step:单个项目的规范治理虽然复杂，但还在可控范围内。如果我们将视角拉高，面对包含几十个子项目的Monorepo（大仓），这些规范该如何复用？构建流程又该如何编排？ 下一节，我们将迎来工程化的“大结局”——《第六篇：宏观——大仓时代：Monorepo 架构的工程实践与工具链选择》。

原文： https://juejin.cn/post/75968905