MomentJs最近宣布，该库现已弃用。对于每周活跃下载Moment近1500万次的javascript社区来说，这是一件大事。说到这里，我开始了一次黑客马拉松之旅，去替换我公司核心图书馆里的Moment。
任何替换过时的库的旅程都必须从找到替代库开始。在Moment的情况下，这不是一件微不足道的任务。Moment提供了很多功能，当与Moment-TimeZone结合使用时，挑战就更大了。
让我们谈谈我的特定用例。我的团队选择遵循不变的Web Apps理念部署我们的Web应用。这里的TL；DR是我们交付完全合格的依赖项和已构建资产的版本。这有助于确保试运行和生产之间的唯一更改是基本配置值。在这里阅读更多关于它的信息。
另一个主要考虑因素是，我在一家国际公司工作，客户来自13种不同的语言，分布在无数个时区。本地化、时区和偏移支持都很关键。
我们从“时刻不赞成”指南中的建议开始，并加入了一些粉丝最喜欢的东西，以确保我们做出了最好的选择。请记住，当时有时间限制，所以我们不能检查所有选项。以下是我们整理的名单：
一旦我们编译了选项列表，我们就得到了每个包的捆绑包大小，包括支持时区和区域设置所需的所有插件/插件。下面是它们的堆叠方式：
由于缺少预建捆绑包而被淘汰。我们需要IWA的单一真理来源，并且不想维护构建过程。
Day.js-2KB，但还需要UTC和时区插件(4KB)以及所有区域设置(26KB)
Luxon-71KB，包含所有内容，并且它依赖于用于区域设置的INTLAPI。
下一步是检查剩下的两个库是否具有我们需要的功能。要做到这一点，我们能想到的最好方法是编写一个测试套件来测试Moment的特性，然后运行每个库来完成挑战。
我们首先编写针对Moment的测试套件，以获得我们信任的值的“静态”真实源。这产生了一组函数名称，然后我们需要使用day.js和Luxon来完成这些名称。
这个测试套件被证明是无价的。我们能够了解到这两个库在我们的用例中是如何工作的，并在day.js中找到了一个严重故障。
事实证明，day.js不能很好地支持夏令时，并且在回购中围绕它有许多未解决的问题。最严重的问题是在进入或离开DST时没有正确计算偏移量。
老实说，到达这里并不是一段很长的旅程。一天多一点的努力让我们对选择鲁克逊有了充分的信心，因为我们的图书馆正在向前发展。它拥有我们需要的所有实用程序、时区支持和区域设置支持。它的捆绑包大小不是最小的，但与513KB的Moment+Moment-Timzone相比，还是有了很大的改进。