Prefer Code Style：从配置地狱中逃离

在我做前端开发的最初几年，几乎每一个新项目的开场白，都是一场无声的折磨：查 ESLint 文档、抠 Prettier 的格式化规则、调试 Stylelint 的插件依赖。一次又一次，从零开始搭建「代码风格配置」，这件事渐渐从必要变成了疲惫，甚至开始吞噬掉我本该投入在业务和设计思考上的时间。

我开始反思：为什么写出风格统一的代码，在现代工程里依然不是一件「默认」的事？为什么每个团队都要重复造一样的轮子？这个问题本身，其实就暴露了我们对代码质量的基础设施建设，有多么缺乏共识。

于是，我动手做了 Prefer Code Style。

不是「配置库」，而是习惯的提炼

我不想再去维护一个复杂的 preset，也不希望别人用了我的配置后，还要手动删删改改才能符合预期。所以我没有追求「最全」「最潮」，而是从我参与过的多个真实项目中抽取出「真正长期有效」的规则。

举个例子，TypeScript 的类型检查配置，我不会把每一条限制都打开，而是只保留那些能实实在在帮我避坑的，比如禁止隐式 any、函数统一返回类型、泛型命名约定。这些看似琐碎的点，往往能在代码重构或多人协作时，避免代价巨大的误解和遗漏。

我甚至保留了一些「不够流行」的格式化行为，因为它们更符合我对可读性的偏执要求。不是所有的规则都要看趋势，有些细节，是习惯沉淀下来的节奏。

模块化，是我对「适配性」的回答

在尝试封装的过程中，我发现最棘手的问题是插件版本冲突。不同项目对 parser 的依赖不一致，直接引用通用配置反而更容易踩坑。最终我决定将 ESLint、Stylelint、Prettier 的规则拆分为模块，按需组合，既避免了冗余依赖，也降低了升级难度。

我还顺带封装了一些工具级集成，比如 VS Code 推荐设置、husky 与 lint-staged 的自动配置。在团队合作中，这些小细节经常能决定一次 PR 流程是顺畅，还是要经历三轮 review 来回 ping。

规则之上，是一种工程默契

Prefer Code Style 的意义，从来不是「少写几行配置」。它真正解决的是：在项目一开始，团队成员是否能对「代码应该长成什么样」有共识。

风格约束，不是风格化，而是秩序感。它让所有人有方向感，也让项目的历史更具延续性。即使几年后重看，也不至于迷失在「这段代码是怎么写成这样的」疑问中。

对我来说，这个项目是一种工程观的外化。它迫使我去深入理解 lint 工具的生态、插件的权衡逻辑、团队协作的细微博弈。而每一条看似枯燥的规则背后，我都会问自己一句话：「如果这个项目要维护五年，它还合适吗？」

回顾与继续前行

Prefer Code Style 是我第一次把「对工程质量的追求」转化为一个系统性的工具。它记录了我从无数次重复劳动中积累下来的经验，也承载着我对「代码是可以被设计的作品」这一理念的执念。

接下来，我打算为它构建更自动化的初始化方案，比如通过 CLI 一键生成配置结构，并与 monorepo 管理工具集成，降低团队接入的心智门槛。同时，我也会持续跟进 lint 生态的更新，定期迭代配置内容，保持它始终与当下的最佳实践对齐。