Allow using either moment or luxon in pluggable fashion

[benmccann]

This PR only allows choosing between Luxon and Moment. The motivation for supporting Luxon is to reduce application size (#4303), add timezone support (#5186), and add support for multiple languages (#5664). Moment is retained for backwards compatibility. Luxon is smaller than Moment especially when using internationalization and time zones. It also improves upon Moment in several other ways such as by having an immutable API.

I do not think it would make sense to allow switching between additional date libraries in the long-term. Supporting switching between Moment/Luxon is not bad since the APIs are so similar, but it would be quite a bit of overhead in the code to support other date libraries as well.

date-fns is the other library that people have been asking us to support. date-fns is tiny and if we use it together with rollup then it introduces very little additional size. So even for users who are using Luxon or Moment in their own application there would not be much additional code size from chartjs using date-fns. I imagine that creating an adapter functionality to allow users to choose between Moment/Luxon/date-fns would introduce possibly as much additional size as just using date-fns directly and would be far more complex. However, date-fns wouldn't make sense to support in my mind until 3.0 when we can drop support for Moment, so that we don't have to create a really complex adapter. Also, more importantly, time zone support is still pending for date-fns which is a blocker and would need to be resolved before we could consider supporting it

With this PR, Moment will still be included in the bundled file. If you're including Chart.js via npm then moment will not be included automatically, but you will get a warning in the case that it is not included. Even if you include Luxon you will still get this warning. The warning can only be tied to a single dependency, so unfortunately we can't print the warning only in the case that neither Luxon nor Moment is included. Printing the warning always seemed perhaps the safer way for backwards compatibility

I updated the installation instructions, but I have not yet updated the README because that change would be deployed immediately. I will update the README when we're releasing Chart.js 2.8.0.

[Allsimon]

any ETA for this ?

[larizzatg]

It will be really nice if there was a way to don't use them if we don't need the time chart functions

[koresar]

Any chance to process this PR @etimberg @simonbrunel? Currently moment.js takes ~50% of my website.

[larizzatg]

Waiting for the PR 🔢

[jazoom]

Is this still happening?

[koresar]

Hey, people.

Let's reach out to the maintainers via Twitter. They might not seeing any of our begging.
Here is what I did: https://twitter.com/kore_sar/status/1051706638367830016
Need one more volunteer to do the same.

I believe this awesome project just needs more core maintainers with merge and publish access.

[etimberg]

I think some more isolation from moment/luxon would help here. We're still using some things that are specific to those libraries such as .startOf().

[NoMaillard]

Wouldn't it be great if this could also include the integration of dayjs, it's super lightweight, compatible with the moment API, has i18n, timezone support

[pokonski]

This would be fantastic to have as I switched from Moment to Luxon, but some dependencies still depend on Moment, like Chart.js

[benmccann]

I like that dayjs is smaller, but it looks like it's missing to quite a few features
It looks like it may not have date parsing: iamkun/dayjs#289
It doesn't have timezones: iamkun/dayjs#46
It's a bit limited for locales, which may be an issue for some of our users: iamkun/dayjs#171
There's also lots of open issues like subtracting days (iamkun/dayjs#384) and lots of unreviewed PRs that would make me nervous depending on it

[simonbrunel]

Sorry for the long wait but I don't think this PR is going in the right direction, mainly because it locks us with an additional lib: Luxon (other reasons detailed in #5960 for those who are brave enough to read). That's why we explored different other approaches and came with another proposal in #5960 (feedback are more than welcome).

[benmccann]

Closing this for now in favor of #5960. Thanks @simonbrunel for all your feedback on the proposal and working to come up with a good solution