发布更好的开发工具：我在推出我的 React Generator CLI 后学到的经验

Source: Dev.to

构建更好的开发工具

几周前，我发布了 rgenex，这是一款面向团队的基于配置的 React 架构脚手架 CLI。
目标很简单：在 rgenex.config.js 中一次性定义你的架构。

最初的反馈令人鼓舞，但很快凸显了一个重要的教训：开发者体验和功能同等重要。生成器技术上可以工作，但如果开发者不信任它，就不会使用。

最大的担忧并非功能本身，而是信心和安全性：

• “我能先预览将要生成的内容吗？”
• “如果它覆盖了已有文件怎么办？”
• “我如何查看可用的生成器？”
• “在 CI/脚本中我能跳过提示吗？”

预览生成的文件

你可以在不写入磁盘的情况下查看将会创建的内容：

npx rgenex g component Button --dry

防止覆盖

如果目标文件已存在，rgenex 现在会在覆盖前提示，防止意外的破坏性生成。

脚本化工作流 / 高级用户

在 CI 流水线或自动化脚本中不希望出现提示时，使用 force 标志：

npx rgenex g component Button --force

检查已配置的生成器

快速列出配置文件中定义的生成器：

npx rgenex list

对开发工具的经验教训

功能可以吸引注意，但能够融入日常工作流的工具必须优先考虑信任、安全和可预测性。

大多数 React 团队并不是因为缺乏编码能力而遇到困难；他们的困扰在于 架构标准随时间漂移：

• 文件夹结构不统一
• 命名规范各异
• 缺少测试或样式
• PR 中反复出现组织结构的评论

rgenex 通过让架构可配置并可强制执行来解决这些问题。

可配置的架构示例

// rgenex.config.js
module.exports = {
  language: "typescript",
  styling: "scss-modules",
  testing: "vitest",

  paths: {
    components: "src/components",
    hooks: "src/hooks",
    pages: "src/pages",
  },
};

一次性定义你的约定，让生成器保持一致性。

行动号召

我会继续根据真实使用情况迭代。如果你在团队中使用 React，欢迎告诉我哪些功能能让这样的生成器足够有用，以至于你的团队愿意采用。

• GitHub: https://github.com/asengar14/rgenex
• npm: https://www.npmjs.com/package/rgenex

感谢所有在首次发布后提供反馈的朋友——正是这些反馈直接塑造了本次更新。