Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

ng the most modern JS features (including the JS date object)</p><h1 id="7803">Planning the migration</h1><p id="f145">Our project is a hybrid project using both React and Backbone.</p><blockquote id="1cdf"><p>Backbone is an old framework that was quite popular before the MVVM era (React, Vue, Angular 2.X)</p></blockquote><p id="cfab">We decided to not care much about backbone as it’s <b>legacy code</b> that needs migration anyway and wasting our time on it is pointless. We then decided to focus exclusively on React code.</p><p id="1b52">I then had to identify all the usages of momentJS within the app (filtering mainly for the import from <code>moment</code> or popular method usages like <code>.format()</code> )</p><p id="e855">Once the identification is done, it ended up in the sprint, it was time to get started!</p><h1 id="dadb">Starting the migration</h1><p id="d09d">Luckily, our project didn’t have too many usages of momentJS. Therefore, it was actually possible to fit the whole migration in a single sprint (without counting the bugs following)</p><h2 id="f287">Creating wrappers for each function</h2><p id="a22a">The main idea around this migration was to make it <b>as futureproof as possible</b>. Before the migration, each usage of momentJS was directly done from the import. But practically, it’s not great as it pushes us to target and change all pieces of code using momentJS.</p><p id="ba85">So we decided to create wrappers for each Date-fns function. Doing that way allows us to have a single place to change in case of another future migration (not anytime soon I hope!). It’s also easier for us to <b>tweak</b> those wrappers in case we’d like to add a new feature to them.</p><h2 id="cb4a">Dealing with JS date objects</h2><p id="2e22">The main difference between date-fns and momentJS is that Date-fns uses the

Options

Javascript Date object for everything! Each manipulation of a date involves a date as input and will output a new one. Unlike momentJS which is not immutable and will just change the same object again and again.</p><h2 id="b3b7">Writing tests</h2><p id="1dce">Writing tests was another interesting bit. Where it was easy to mock some momentJS objects, Date-fns using the JS date object was making it different. Instead of telling moment to be set to a specific date when instantiated, I had to use the fake timers from Jest to change the testing environment date and set it to a specific one.</p><h1 id="1174">The after migration</h1><p id="4da2" type="7">Migrating doesn’t finish when the code is done</p><p id="71a3">For some time, the whole branch is in testing by our QA engineers and this is a time during which other people may need to write new code involving dates. But as the feature is not here just yet, they still need to use momentJS to avoid having many conflicts when merging the migration in the main branches.</p><p id="2f9e">Another interesting thing to consider is your team. Most of them never used this new library and they need some basic training/tour around the new tools.</p><p id="eba3">Of course, migrating was involving bugs that sometimes were not that obvious, especially around specific behaviours. We had to reconsider some of them as they were showing some inconsistencies. But overall, that was pretty smooth!</p><p id="35c2">Migrating away from momentJS was a very insightful experience for me! I could enjoy the responsibility to investigate and suggest libraries to my team, but also lead the whole migration and training afterwards.</p><p id="3cc7">Let me know in the comments your experience or questions around that, I’d be happy to hear from you!</p><p id="dbab">Thank you for reading!</p></article></body>

Migrating away from momentJS

I had to lead the migration from moment to date-fns, here is my experience

Photo by Tima Miroshnichenko: https://www.pexels.com/photo/analog-clock-in-macro-photography-7033891/

Some time ago, the momentJS team decided to move their library to maintenance mode, meaning that they are not going to push any new feature anymore. Only bug/security fixes.

My company tries to keep up with the latest technologies and avoid a maximum the tech depts, which is why they decided lately to move away from momentJS. I took care of this process, let me tell you how it went.

Choosing the right library

The first step was about picking the right library for us. Migrating from a date library to another is not an easy thing and we don’t want to do it again anytime soon.

By having a look, I could identify three libraries that could be interesting which are:

Date-fns
DayJS
Luxon

Those three libraries are interesting for the following reasons:

A decent amount of stars on Github
A large enough community (Easier when looking for help on Stackoverflow)
An active development
Usage of modern JS

I could then present those three libraries to my team and could finally make a decision. Even though I was pushing for DayJS because I used it before, we decided to go for Date-fns as it’s the most complete one and is also using the most modern JS features (including the JS date object)

Planning the migration

Our project is a hybrid project using both React and Backbone.

Backbone is an old framework that was quite popular before the MVVM era (React, Vue, Angular 2.X)

We decided to not care much about backbone as it’s legacy code that needs migration anyway and wasting our time on it is pointless. We then decided to focus exclusively on React code.

I then had to identify all the usages of momentJS within the app (filtering mainly for the import from moment or popular method usages like .format() )

Once the identification is done, it ended up in the sprint, it was time to get started!

Starting the migration

Luckily, our project didn’t have too many usages of momentJS. Therefore, it was actually possible to fit the whole migration in a single sprint (without counting the bugs following)

Creating wrappers for each function

The main idea around this migration was to make it as futureproof as possible. Before the migration, each usage of momentJS was directly done from the import. But practically, it’s not great as it pushes us to target and change all pieces of code using momentJS.

So we decided to create wrappers for each Date-fns function. Doing that way allows us to have a single place to change in case of another future migration (not anytime soon I hope!). It’s also easier for us to tweak those wrappers in case we’d like to add a new feature to them.

Dealing with JS date objects

The main difference between date-fns and momentJS is that Date-fns uses the Javascript Date object for everything! Each manipulation of a date involves a date as input and will output a new one. Unlike momentJS which is not immutable and will just change the same object again and again.

Writing tests

Writing tests was another interesting bit. Where it was easy to mock some momentJS objects, Date-fns using the JS date object was making it different. Instead of telling moment to be set to a specific date when instantiated, I had to use the fake timers from Jest to change the testing environment date and set it to a specific one.

The after migration

Migrating doesn’t finish when the code is done

For some time, the whole branch is in testing by our QA engineers and this is a time during which other people may need to write new code involving dates. But as the feature is not here just yet, they still need to use momentJS to avoid having many conflicts when merging the migration in the main branches.

Another interesting thing to consider is your team. Most of them never used this new library and they need some basic training/tour around the new tools.

Of course, migrating was involving bugs that sometimes were not that obvious, especially around specific behaviours. We had to reconsider some of them as they were showing some inconsistencies. But overall, that was pretty smooth!

Migrating away from momentJS was a very insightful experience for me! I could enjoy the responsibility to investigate and suggest libraries to my team, but also lead the whole migration and training afterwards.

Let me know in the comments your experience or questions around that, I’d be happy to hear from you!

Thank you for reading!