[pickers] Request to Remove Moment.js Dependency from @mui/x-date-pickers

[MattCGao]

Summary

The moment library, which is currently a dependency of @mui/x-date-pickers, is deprecated and no longer maintained. Moreover, moment has known drawbacks, including large bundle size and lack of tree-shakability, which can impact application performance and modern development practices. I request the MUI-X team to consider removing the moment dependency and transitioning to more lightweight and modern alternatives like date-fns, dayjs, or providing hooks for custom date libraries.

Examples

1. Modern alternatives like dayjs and date-fns provide similar functionality with much smaller bundle sizes and better tree-shaking support.
2. Many widely used libraries, such as react-datepicker, have already deprecated or removed moment in favor of more modern solutions.
3. By removing moment, developers can avoid the need to include multiple date libraries in their projects, especially since many projects are already migrating away from moment.

Motivation

1. Performance:

   • moment significantly increases the bundle size due to its monolithic architecture.
   • Smaller alternatives like date-fns or dayjs improve performance and reduce build size.

2. Deprecation:

   • moment is officially deprecated, and its use is discouraged in favor of modern alternatives.
   • Including a deprecated library may affect long-term maintainability and compatibility of the @mui/x-date-pickers package.

3. Flexibility:

   • Providing hooks or options for developers to bring their own date libraries increases flexibility and aligns with modern library development practices.
   • Many teams already standardize around libraries like date-fns or dayjs and prefer not to bundle unused dependencies like moment.

4. Modern Development:

   • The MUI-X library should reflect best practices in modern JavaScript development, focusing on lightweight, modular, and well-maintained dependencies.

Search keywords: moment.js, @mui/x-date-pickers, remove moment, date libraries, bundle size, performance

[michelengelen]

Hey @MattCGao ... the reasoning seems very valid to me.
I'll add this to the board for the team to discuss.

[LukasTy]

Hello @MattCGao, thank you for creating this issue. 🙏
Could you clarify why you suggest removing the option for users preferring not to refactor all their applications to a different date library but use up-to-date @mui/x-date-pickers? 🤔

Yes. moment is deprecated and has its drawbacks, but in all honesty, it is probably the least buggy library, certainly better than dayjs in this regard.

Usage of moment is optional and does not impact users who choose a different library/adapter. 🤔

Given the above arguments, I don't see a clear reason for removing the suggested library/adapter.
Please correct me if I'm wrong or missing something here @flaviendelangle?

[flaviendelangle]

We don't enforce the usage of moment.js, it's not even the default on our doc.
And it's an optional peer dependency, not a dependency, so if you use another data library, you don't have to install it.

I fully agree that I would not recommend anyone to start a new application today using moment.js, depending on your needs dayjs will probably be better on simple application and luxon on more advanced ones (at least that's my preferences at the moment).
But for people already using moment.js and looking for a set of Date and Time Pickers, I don't see why we would remove them the ability to use ours.

At some point, we could discuss adding a note on the doc reminding that moment.js is deprecated and that we advise against using it if possible.
But I would not remove it before a long time.

[flaviendelangle]

moment significantly increases the bundle size due to its monolithic architecture.
Smaller alternatives like date-fns or dayjs improve performance and reduce build size.

That's false. date-fns is not significantly smaller than moment.js with the set of exports we need.
Only day.js is significantly smaller as long as you don't need timezones (and even with them it's still quite small).

Providing hooks or options for developers to bring their own date libraries increases flexibility and aligns with modern library development practices.

It's already the case

Many teams already standardize around libraries like date-fns or dayjs and prefer not to bundle unused dependencies like moment.

People don't have to install / bundle moment.js

The MUI-X library should reflect best practices in modern JavaScript development, focusing on lightweight, modular, and well-maintained dependencies.

It's subjective but I think we do, and at least moment.js optional support don't go against any of those

Not answering all fo the statements, but unfortunately most of them are incorrect.
If you are using our components, what made you think you had to install moment.js?

[github-actions]

The issue has been inactive for 7 days and has been automatically closed.