通过编写自己的方法或dayjs来替换moment.js

Question

我正在开发一个项目，其中

moment.js

被用作日期处理库。但由于

moment.js

项目状态页面 说了以下内容：

我们现在普遍认为 Moment 是一个处于维护模式的遗留项目。它没有死，但确实完成了。
实际上，这意味着：
• 我们不会添加新的特性或功能。
• 我们不会将 Moment 的 API 更改为不可变。
• 我们不会解决树抖动或捆绑包大小问题。
• 我们不会进行任何重大更改（没有版本3）。
• 我们可能选择不修复错误或行为异常，特别是如果它们是长期存在的已知问题。

此外，最近遇到一个错误，在 firefox 和 safari 浏览器上使用 momentjs 时，它会导致应用程序出现一些问题，该错误在其他浏览器上无法重现。

在存储库中，有来自

moment.js

库的大约 30-35 种方法。所以我在想 将其替换为以下选项之一：

• 选项1：

  day.js

  库
• 选项2：在自己的代码库中从头开始编写所需的功能

选项1：

day.js

库

将

moment.js

替换为

day.js

。这似乎很简单。不需要太多努力。

这种方法的优点：

• 非常简单的方法，这只需要严格的测试。
• 实用功能与

  moment.js

  类似，替换代码也不费力。

这种方法的缺点：

• 我们不会保留细粒度的级别控制，如果出现任何问题，需要等到包中修复错误
• 没有树木摇晃

选项2：通过复制所需的day.js实用程序在自己的代码库中编写所需的函数

代码库中使用的任何函数都将完全在同一个代码库中编写

这种方法的优点：

• 我们将保留精细的级别控制，如果引入错误，我们可以快速解决
• 摇树

这种方法的缺点：

• 耗时
• 如果直接复制 days.js 实用程序，则在将其复制到代码库之前需要完全理解代码

我想知道哪种方法更合理？

Answer 1

考虑到紧迫性和对快速解决方案的需求，选项 1（使用 day.js）似乎是适合您情况的更务实的选择。它提供了快速、直接的迁移路径，并且 moment.js 和 day.js 之间 API 的相似性使迁移更加顺利。

虽然选项 2（编写您自己的函数）提供了更多控制，但它的缺点是耗时，并且如果未彻底实现和测试，可能会引入错误。此外，在不完全理解代码库的情况下直接从 day.js 复制实用程序确实可能会遗留任何现有的错误。