模板开发的体验革命：为什么 Markdown 是插件化的最后一公里？

donecoding
29 阅读4分钟

前言

在前面的两篇文章中，我们聊到了组件库的样式选型，以及如何通过插件化架构将 CLI 与模板解耦。今天，我们聊聊这套系统的核心——模板开发本身。

很多脚手架工具在追求“强大”的路上，往往会陷入复杂度的陷阱：要么需要开发者学习复杂的 AST 转换，要么需要编写晦涩的配置。而我一直坚持的原则是：一个好的工程化方案，应该让开发者感觉不到“新知识”的负担。

这就是为什么我最终选择了 Markdown 代码块 + Lodash Template 作为插件化的最后一公里。

一、 零学习成本：回归最原始的“所见即所得”

在我的插件系统中，开发一个新模板插件的过程极其自然。

  1. 像写代码一样写模板

如果你想定义一个 Sass 模板，你不需要操作任何 JSON 对象，只需要在一个 .md 文件里写下：

markdown

### Sass 样式模板
```scss
$prefix: '<%= prefix %>';

.#{$prefix}-<%= kebabCaseName %> {
  display: flex;
  color: var(--primary-color);
}
```

请谨慎使用此类代码。

为什么这样做？

  • 天然高亮：  你在写这段模板时，编辑器会根据 scss 标记提供完美的高亮和缩进。
  • 无需逃逸：  你不需要处理复杂的字符串转义。Markdown 的代码块容器就像一个“沙箱”，它保护了模板语法的纯粹性。
  1. Lodash Template：老牌但无敌的动力源

我没有发明新的模板语法，而是直接使用了 Lodash Template。
它支持标准的 <%= %> 插值，也支持 <% if (...) { %> 逻辑判断。对于任何熟悉 JavaScript 的开发者来说，这几乎是零学习成本的。你可以在模板中自由使用 toUpperCase()、replace() 等原生 JS 方法来处理你的组件名。

二、 核心实现：极致轻量的字符串解析

正如前文所说，我并没有使用 AST，而是采用了字符串切割的策略。

  1. 为什么“字符串切割”就够了？

组件模板的本质是片段拼接。我们只需要识别出 Markdown 中的代码块起始位（```），提取中间的内容，然后将其作为原始字符串丢给 Lodash 处理。

这种实现方式不仅代码量极少（通常几十行正则或字符串逻辑即可搞定），而且极其稳健。它不关心你的 TS 语法是否合法，也不关心你的 Sass 是否用了最新的提案，它只负责变量替换。

  1. 格式化的“最后一步”

字符串拼接最容易产生的问题就是缩进混乱。
为了解决这个问题，我的 CLI 工具在完成模板渲染后，并不会直接退出，而是会调用宿主环境的 Prettier（如果存在）对生成的文件进行一次静默格式化。

  • 结果：  模板插件只需关注逻辑，最终产出的代码依然整洁如手写。

三、 插件系统的价值：自由选择的权利

通过这一整套基于 Markdown 的插件化设计，我真正实现了选型的自由：

  • 样式自由：  如果你想用 Sass，安装 @my-ui/plugin-sass；想换成 UnoCSS，只需切换到 @my-ui/plugin-unocss。
  • 框架自由：  逻辑模板（.tsx / .vue）同样封装在 MD 插件中，CLI 核心逻辑无需改动一行代码。

这种 “样式可插拔、模板可视化、逻辑零成本” 的状态，才是理想中的组件库基础设施。

四、 总结：工程化的尽头是务实

回顾这三篇文章，我们从样式选型聊到架构解耦，再到模板载体的选择。这其中贯穿始终的逻辑只有一条：解决实际痛点，拒绝过度设计。

  1. 选型上：  我们选择 Sass + UnoCSS + CSS 变量，是因为它们在 2026 年的性能与灵活性之间达到了最佳平衡。
  2. 架构上：  我们借鉴 ESLint 实现插件化，是为了让 CLI 保持轻量，让模板获得自由。
  3. 实现上：  我们坚持使用 Markdown + 字符串解析，是为了保证模板的最优开发体验和可读性。

写在最后：
技术方案没有绝对的对错，只有是否契合当前的工程语境。这一套架构是我在长期实践中沉淀出的、最符合我直觉的解法。希望这些关于“解耦”与“务实”的思考，能给你在构建自己的工具链时带来一点启发。

本专栏到此结束。如果你对这套基于 Markdown 的组件生成方案有任何实现上的细节疑问，欢迎在评论区与我交流

avatar
文章
阅读
粉丝