Radashi 与 Radash 的对比

如果您已经使用过 Radash，您自然会想知道 Radashi 更好在哪里。首先，也是最重要的，Radashi 是积极维护的。在我看来，仅此一点就使 Radashi 成为更好的选择。

话虽如此，鉴于两个项目的当前状态，请允许我概述一下它们的比较情况，并简要介绍一下我对未来的愿景。我将尽量全面地列出我认为使 Radashi 成为显而易见选择的差异：

• 明确的设计理念

  • 为了指导我们的决策，我尝试将“Radashi 的理念”阐述为一套设计原则。
  • 这是一份活文档，因此我期望它能根据社区的反馈随着时间的推移而演变。
  • 我相信拥有这样一份文档将使贡献者更容易理解项目的目标和方向，从而更容易贡献符合项目愿景的功能。
  • 它也有助于解决贡献者之间可能出现的任何分歧。
  • 该理念将在文档中有自己的页面，但您可以查看初稿以了解其内容。

• 更高的代码质量

  • 这是 Radashi 最难以证明的好处之一（除了我们修复了错误，因此 bug 更少这一事实）。
  • 虽然我们的前身 Radash 的代码质量大部分很好（无意贬低），但我和其他贡献者已经能够进行许多改进。
  • 我相信这种质量差距只会随着时间的推移而扩大，因为我们还没有完成对从 Radash 继承的代码的改进。我希望随着您的使用，Radashi 的质量会变得更加明显。

• 更多的函数

  • 我们正在积极寻求引入覆盖流行用例的新函数。
  • 社区拥有最终决定权。如果有对某个函数的需求，并且该函数符合 Radashi 的理念，那么这个函数肯定会被添加。

• 性能基准测试

  • 每个拉取请求都会使用我们的基准测试套件与主分支进行比较。
  • 这确保了 PR 不会引入任何性能回归。
  • 这也确保了与性能相关的 PR 在统计上是显著的。
  • 有计划在支持相同用例的地方添加与 Lodash 的对比基准测试。

• 打包体积影响

  • 当 PR 添加或修改函数时，会比较函数新旧实现的压缩后字节大小，并在 PR 中报告。
  • 这有助于我们避免引入任何不必要的膨胀。

• 欢迎新的维护者

  • 我最不希望的就是成为项目的唯一维护者。
  • 我设定了比大多数项目更低的加入核心团队的门槛，因为我希望尽可能多的热情贡献者帮助指导开发。
  • 这是我尽可能避免响应迟缓问题的尝试。Radash 是一个单人项目，结果项目因维护者倦怠而受到影响。
  • 为了缓解拥有庞大维护者团队可能产生的安全问题，目前我是唯一有权发布到 NPM 的人。我希望在不久的将来这种情况会改变，这样我就不再是发布流程中的瓶颈。

• 夜间 Beta 版本发布

  • 每天晚上 UTC 时间 5:00，如果当天有任何 PR 被合并，就会发布一个 radashi@beta 版本到 NPM。
  • 这意味着您第二天就可以使用您或他人的贡献。
  • 这允许快速的开发周期，并且能够使用最新、最强大的功能或修复，而无需等待稳定版本。
  • 我计划对破坏性变更做同样的事情，基于 next 分支发布夜间的 radashi@next 版本。

• 更宏大的愿景

  • 在项目第一个真正版本发布后不久，我计划将重点转向 Radashi 的更宏大愿景。
  • 我还没有准备好分享那是什么，但我可以说，它专注于使 Radashi 尽可能易于定制。
  • 该愿景还包括使 Radashi 减少对核心团队的依赖，允许社区在没有守门的情况下协作，同时仍然使用 Radashi 的代码库和理念作为协作的共同基础。
  • 时机成熟时，会有一篇关于这个的博客文章。

• 翻译的文档

  • 我们计划支持多种语言，以便吸引更广泛的受众并吸引非英语使用者为项目做出贡献。
  • 为了启动这项工作，我将使用 LLM 进行初始翻译。每次文档更新时，这都会在 GitHub Action 中运行。

• “浏览器支持”页面

  • 文档将明确说明 Radashi 支持哪些浏览器，而无需传统的转换（polyfills）。
  • 每次文档更新时都会更新此页面，因此它总是相对最新的。
  • 作为我们自动 linting 过程的一部分，我们验证此浏览器支持未被破坏。
  • 您可以在这里找到该页面。

• “Lodash 兼容性”页面

  • 文档将有一个专门用于在有重叠的地方比较 Radashi 和 Lodash 的页面。
  • 这应该有助于 Lodash 用户切换到 Radashi。
  • 当页面准备好后，您将可以在这里找到它。（我几乎写完这个页面了。它是从一个 Supabase 表生成的，我在其中跟踪了 Lodash 的哪些函数已在 Radashi 中实现。）

• 其他一些小事情

  例如… (点击展开)

  • 受保护的主分支：PR 必须通过自动化检查才能被合并。即使我有这个权限，我也永远不会直接向 main 分支推送修复或功能。

  • 约定式提交 (Conventional commits) ：我添加了一个提交消息 linter，以确保所有提交都遵循

    约定式提交

    规范。

  • RFC 流程：新功能和破坏性变更通常会

    作为 RFC 提交

    以鼓励社区参与决策过程。

  • 预览版发布：如果您等不及 PR 被合并，PR 作者可以评论 /publish 来将 PR 的预览版发布到 NPM 以供立即使用。

  • 生成的变更日志 (Changelog) ：本质上是一个过滤后的提交历史记录，排除了非代码更改，以便于查看新内容。

  • 高层次的发布说明 ：这些将包含每个版本中变更的高层次解释和代码示例。

  • 贡献脚本：添加了像 pnpm add-function 这样的脚本来简化贡献过程。

  • JSR.io 包：如果您使用 Deno 或者您只是认同 JSR.io 的理念，您可以使用 JSR.io 包 而不是 NPM 包。

  • 更好的工具链：我已将项目切换为使用 Vitest 进行测试（而不是 Jest），使用 Biome 进行源代码的 linting/格式化（而不是 TSLint/Prettier），以及使用 PNPM 进行包管理（而不是 Yarn）。

  • 更易于复制粘贴：如果 Radashi 的某个函数不能满足您的需求，您可以轻松地将其复制粘贴到您的项目中并按需修改，因为我们的函数总是像您的项目一样从 radashi 导入。

最后，我希望 Ray Epps（Radash 的创建者）会为我们带领 Radashi 所达到的高度感到自豪。也许他甚至会在某个时候加入核心团队。谁知道呢？

如果您有任何问题或意见，请跳转到引发这篇文章的 issue 并留下评论。