Discovery: moment.js alternative

[rianfowler]

@markgreenburg commented on Fri Aug 03 2018

Problem:

Moment.js is ~10x the size of React, gzipped (>60K). This seems to be the case despite removing locales via new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/). Further, imports can't be modularized so we can't take advantage of tree shaking. This is a really big dependency, and we don't really use many fancy features to make moment worth all this weight.

Discovery:

• Estimate & quantify benefit from switching to an alternative library
• Document all the different moment functions we use in vets-website
• Explore alternatives
  • Two mentioned here are date-fns and day.js
• Explore lift to switch. Note that there're also a moment-setup.js in platforms/site-wide as well as a utils/date/index.js in addition to the usage across our apps.

---

@cvalarida commented on Fri Aug 03 2018

@markgreenburg Did you measure this in the bundle served to the client or using VSCode's fancy new import size feature? I'm wondering if the latter doesn't factor in that webpack ignore plugin.

[bkjohnson]

For the alternatives, I think date-fns seems like the way to go based on this comparison table. It supports tree shaking so that we can further reduce bundle size, and it also supports timezones which day.js doesn't.

Here is a comparison of gzipped bundle sizes from the previously linked table:

• moment 69.6K
• date-fns 13.4K (without tree-shaking)

If we configured webpack to allow tree-shaking we would be able to create a bundle with date-fns taking up even less space, since we wouldn't include any of the functions that aren't used.

[bkjohnson]

Here are the moment functions that are currently in use:

• .add()
• .asDays()
• .clone()
• .daysInMonth()
• .diff()
• .duration()
• .endOf()
• .format()
• .fromNow()
• .isDST() - no 1:1 equivalent in date-fns
• .isAfter()
• .isBefore()
• .isBetween()
• .isSame()
• .isSameOrBefore()
• .isSameOrAfter()
• .isValid()
• .locale()
• .month()
• .parseZone()
• .startOf()
• .subtract()
• .toDate()
• .toISOString()
• .unix()
• updateLocale() - in moment-setup.js
• .utc() - no 1:1 equivalent in date-fns
• .utcOffset()- no 1:1 equivalent in date-fns

In order to make the switch to date-fns we would have to refactor platform/app code and tests. We may encounter code with little or no test coverage that is being modified, and we would have to add tests in those scenarios to ensure that the dependency switch & associated refactoring doesn't break anything.

[bkjohnson]

I think it may be wise to hold off on this for a bit. date-fns doesn't provide a way of changing the default locale, and we've run into a few formatting issues where the default doesn't match what our content guidelines demand. With moment, we circumvented those issues in the moment-setup.js file, but date-fns doesn't give us a comparable updateLocale() function.

We could pass an options object each time we called format, or we could create a wrapper function that used the locale that we wanted, but those approaches are just extra hassle that would require more maintenance.

[meganhkelley]

Need to:

• Profile the apps that are still using moment.js
• Ask those app teams to stop using moment