Any thoughts on migrating away from moment to a more modularized date library like date-fns?

[dchhetri]

moment.js is huge library and isn't modularized. There is a issue created for moment modularization but to be frank I don't think it will be resolved anytime soon. I'm wondering if there are any thoughts on moving away from moment into a modular date library like date-fns?

[martijnrusschen]

Good question. We have multiple discussion about moving away from moment to libraries like Luxon, or making moment optional so that you can use any library for your date picker.

Ideally, I think it would be great if the date picker could handle multiple date engines. This allows customers that use the library they prefer (for example, at HackerOne we use moment at many places in the app and that's why we choose this library for the date picker) but someone else could use date-fns and might not want to include moment just for this date picker.

[dchhetri]

That would be ideal, do you think we can use contextAPI to help assist the peer deps somehow to allow users to use any date library long as they follow some standard format

[jrop]

In my opinion, libraries such as this should be as lean as possible. That would mean:

• Store dates internally using JavaScript's own native Date
• Perform any arithmetic using specific functions from a lean library, such as date-fns (all unused imports get left out of the bundle).
• Expose selected dates using the native Date core class, (e.g., onChange(date: Moment) changes to onChange(date: Date))

In one of my own projects, I created a lib month-info that returns the "shape" of any given month that I used to display info. Could this project take this approach to migrate away from moment?

[nateabele]

Just ran into this. We're trying to get off of Moment as well, but recently introduced a dependency on react-datepicker, which is the last transitive dependency on Moment at this point.

In my opinion, libraries such as this should be as lean as possible. [...]

Seconded. After reviewing the codebase, it doesn't seem like abstracting for different date libraries would be worth the conceptual overhead or the code weight.

@martijnrusschen I'd be happy to submit a PR based on @jrop's 3 bullet points. I think I can even do it in such a way that it's not a BC break for existing Moment + react-datepicker users. Thoughts?

[treyhoover]

@nateabele Let me know if I can help. This would remove our last moment.js dependency as well.

[nateabele]

@treyhoover I kinda don't even want to start on it unless I know it'd be accepted in principle... react-datepicker seems to be the only reasonable date picker out there for React, but, there seems to be enough demand for this that maybe a fork is worthwhile if not.

[nateabele]

@martijnrusschen Ping! Just wanted to check in one more time. Any thoughts?

[jrop]

@nateabele I took a whack at creating a PR for this, but quickly abandoned it as I realized I did not have enough time + project_familiarity to finish it :frowning_face:

[grantglidewell]

Anything new on this? Im working on bringing down the bundle size of my app and moment is a huge chunk of it currently.

[martijnrusschen]

Moment.js was removed in #1527, starting v2.0.0, this package doesn't use Moment anymore.