WIP: Replace moment with luxon

[prayerslayer]

Hi, this is work-in-progress. I just wanted to get the ball rolling on #1283 / #382 and prevent someone else from doing duplicate work. Is there a dev branch or similar? I wouldn't want to merge this in master.

Plan:

• Add luxon
• Refactor date_utils to work with that and make its tests pass
• Figure out localization & formatting
• Update examples and docs (do separately I actually need this to test code correctness)
• Revert cosmetic changes in examples, apparently my prettier config is different, oops
• Remove cloneDate
• ?????
• Profit

[aij]

Shouldn't most of these changes be in date_utils.js, or rather a new, luxon-based version of that file?

For example, rather than removing cloneDate, the luxon version of that would just be the identity function.

Or is the plan to drop support for moment?

[prayerslayer]

Shouldn't most of these changes be in date_utils.js, or rather a new, luxon-based version of that file?

If you add luxon support alongside moment, yes, but when I replace moment I need to change all the examples, which contain userland code :)

rather than removing cloneDate, the luxon version of that would just be the identity function.

That's a good suggestion, thanks.

Or is the plan to drop support for moment?

I tried to probe what is desired in previous issues/pull request, but feel I got no definitive answer, so my plan currently is to drop moment entirely, yes. Mostly because it's easier, we only need to bump the major version. A preview version can be published under a luxon npm tag before doing that to collect feedback and find bugs that aren't covered in tests. If bugfixes/features are added meanwhile it should be easy to merge them into the preview branch as well, if PR authors don't add moment-code outside of date_utils.

Does that make sense?

[aij]

Fine by me. 😃 It will be a major breaking change, but at CCAP we're handling most conversions to/from moment in a single place, which should be relatively easy to switch to luxon. I don't know how common that is though.

How long would we expect to maintain a 1.x branch while users transition?

[prayerslayer]

How long would we expect to maintain a 1.x branch while users transition?

I don't have experience running a popular library, so I don't really know what a time frame would be. 3–6 months of backporting bugfixes, but not adding features feels alright to me. Maybe we could release a codemod to make the transition easier? The necessary changes are mainly mechanic, subtle differences exist though.

[martijnrusschen]

If you add luxon support alongside moment, yes, but when I replace moment I need to change all the examples, which contain userland code :)

I have no clear picture of the usage of Luxon vs Moment currently but would it be an idea to implement it in a way that we can run Luxon next to moment? Giving the users the flexibility to use whatever library they want to use (Luxon, Moment, Pure JS dates, etc.) Another route would be to remove moment altogether (something like #1059).

[prayerslayer]

I have no clear picture of the usage of Luxon vs Moment currently

If NPM download stats are worth anything, moment is ~240x as popular 🙃

would it be an idea to implement it in a way that we can run Luxon next to moment? Giving the users the flexibility to use whatever library they want to use (Luxon, Moment, Pure JS dates, etc.)

I mean yeah, that technically works and sounds nice, but there are a couple of things to consider:

• Build & distribution: I guess you could add a property to react-datepicker which specifies the date backend, and then import that async as needed.
• Differences in implementations: JS Dates and date-fns don't support timezones, moment has a mutable API (vs immutable of luxon and date-fns), weekday depends on locale in moment but doesn't in luxon, only moment has custom locales etc. For me an outcome of Discussion: Optional moment.js #1059 was that either the lowest common denominator of all possible date backends is implemented, or only very similar date backends are supported. Otherwise this grows too complex to maintain and use.
• Documentation: Basically there'll be one set of documentation per date backend, definitely more effort to maintain than now. Also educating developers about the new possibility/complexity will take more time than just saying "use luxon from $SOME_POINT_IN_FUTURE on."
• Bugfixes: You now need to test them with all the date backends.

Personally I think that's too much, but it's up to you to decide I guess. I'm fine with whatever decision you make :)

[acontreras89]

My two cents (with barely 5 minutes of library usage):

• 👍 to removing moment altogether
• ❤️ raw js dates, date-fns for 🎨

I'd leave out everything else for users to implement. Although I haven't worked with luxon, no idea how that is

[SampsonCrowley]

Id definitely be on the Raw JS dates bandwagon. I hate including extra libraries where I van avoid it. and ES6/7 makes working with most things in vanilla js pretty simple compared to how it used to be. Id be happy to help out if someone has something specific that needs work

[martijnrusschen]

Moment was removed in #1527.