In deprecating the library, Moment’s maintainers declared it a “legacy project in maintenance mode.” That meant the library would continue to exist with limited support and without any new features. Moment’s maintainers discouraged its use in new projects and suggested users consider more modern alternatives. Moment, they said, was no longer the best option for modern applications for a few reasons:
- Moment.js objects are mutable, which can cause hard-to-diagnose problems.
- Moment doesn't work well with modern "tree shaking" algorithms—used to remove dead code—so it tends to increase the size of web application bundles.
As developers at Tidelift, we know that continued use of deprecated open source software can lead to problems, or even open back doors for malicious activity. (More on deprecated npm modules can be found in this blog post.) So earlier this year, we removed the use of Moment in our code base.
But Moment has been deprecated for a couple years now. Why did it take us so long?
Like many other applications, Tidelift used Moment extensively to handle dates and times in many places around the application. Removing Moment would require significant changes to large chunks of the codebase. Those changes require testing, both manual and automated, and those sorts of disruptions can be costly.
Before changing anything, we had to find a replacement library. If you’re dealing with a deprecated library, you’d better hope it’s a popular one for which there are already good replacements. We got lucky with Moment. It had been so popular for such a long time that developers had been working on replacements for years. We considered three alternative options, each with its advantages:
- Luxon was started by a member of the Moment community and has a similar object-chaining API as Moment, but with immutable objects rather than mutable ones, which helps prevent subtle bugs.
- Day.js also has a similar API as Moment, and in many instances can be used as a drop-in replacement for Moment.
While there was extensive use of Moment in the Tidelift application, the way we used it was quite simple; we used no complicated date transformations with Moment, and none of our code relied on mutated Moment objects. So we chose Day.js as a drop-in replacement for Moment. Once we got organizational buy-in to make the switch, it was time for brute force replacement and testing. There was a bit of tweaking and a few bugs to fix as we adapted to the particulars of the new library. And then, we were done with Moment.
While the Day.js API is nearly identical to the Moment API, there are a couple differences to watch out for if you decide to make the switch:
- Day.js uses a core + plugin system. For certain format strings and features, you will need to register the appropriate plugins.
- Day.js objects are immutable.
Of course, there is no guarantee that Day.js or any other library will not also be deprecated at some point in the future. Whether or not we move to a different library later on, removing Moment helped us reduce bundle sizes by a significant amount, and more importantly, we are no longer relying on deprecated software.
Do you know if all the open source packages in your application’s software supply chain are actively maintained? Tidelift can help you find out. Watch this video to learn how to generate software bills of materials and how to keep them up to date.