Do not require moment.js

[hiendv]

Expected Behavior

Chart.js requires moment.js but only uses some of its functions. The moment.js size is too large for production. I want to reduce the bundle size by using a date-time library supporting tree-shaking

Current Behavior

I have a problem with the bundle size of moment.js in production. Moment.js does not support tree-shaking so its size is kinda overwhelming.

Possible Solution

Using date-fns instead of moment.js. Date-fns offers similar APIs and support tree-shaking. There are some comparisons between date-fns and moment.js

• Add a brief comparison with Moment.js? date-fns/date-fns#275 (comment)
• Add a brief comparison with Moment.js? date-fns/date-fns#275 (comment)
• Modularize moment.js, make the core as light as possible moment/moment#2373 (comment)

Context

Chart.js is the only library requiring moment.js in my application. I did some searches and date-fns seems to be a decent choice.

Environment

• Chart.js version: 2.5.0
• Browser name and version: Chrome v59.0.3071.29

[benmccann]

I think lack of time zone support would be the main obstacle

But this brings up another good point. It seems like it'd be helpful for chartjs to support tree shaking. If I'm only using one chart type then why should I have to include the code for all chart types? I believe moving to ES6 modules would fix that. Perhaps we should have a separate issue to track that

[simonbrunel]

@benmccann not sure we need a new ticket, I'm already on reorganizing the - weird - require() strategy in order to migrate to ES6 modules and finally switch to Rollup instead of Browserify. Tree shaking would be great for external dependencies, but we don't want to get rid of our own methods that are not referenced in the main repo (e.g. deprecations or methods used by external modules).

I remember a few tickets that suggested other date/time libraries: an idea would be to have our own time/date wrapper and provide a few adapters to popular libs such as moment or date-fns. The adapter could be automatically selected based on some global detection or enforced by the user.

And maybe we should deprecate the Chart.bundle.js?

[benmccann]

Oh, that's awesome that you're already working on a migration to ES6 modules.

Btw, I wasn't suggesting been would tree shake our own modules. Rather that if we use ES6 modules then end users can tree shake out chartjs modules that they don't need.

[simonbrunel]

Agree, that would be convenient, though I think it's for "advanced" users that want to build the lib by their own. For others, it would be great if Chart(.min)?.js could detect if a compatible date/time lib is already loaded by the user and use it. But also allow users to write custom adapter for their preferred date/time lib.

[etimberg]

Funny that #4461 got filed about this very topic today

[hiendv]

Does chart.js use moment timezone? How does a chart library require timezone support? Date/time library adapters are expensive, IMO. Anyway, tree-shaking is kinda inconsistent across bundlers. E.g. Webpack cannot prune unused pure imports, rollup can.

[benmccann]

Chart.js doesn't use time zone itself, but It looks like some people use the client-side time zone support that moment provides to format/parse chart.js labels. E.g.: https://stackoverflow.com/questions/40891462/chart-js-display-control-timescale-time-zone/41715066#41715066

It would be cheaper from a library size perspective to do any timezone handling on the server side, so I'd be fine advising people to do that instead.

[hiendv]

By expensive I mean, the burden of building adapters which supports a variety of date/time libraries should not be on the Chart.js end.
If users want to manipulate the labels, they should use their own library.

[simonbrunel]

I wasn't thinking writing tons of adapters, but at least one (moment.js?) and accept contributions from users who want to interface with another lib. The idea behind this would be to keep the Chart.js code independent of any third party date/time lib and allow users to make their project depends on whatever lib they want.

Because right now, switching to another lib may be a breaking change for external charts/plugins and I would prefer not to have to change again for a better library if someone else think that finally Chart.js shouldn't use date-fns :)

Edit: though, I totally agree that moment.js may not be the best dependency for Chart.js.

[simonbrunel]

For example: #3533

[hiendv]

I understand the benefit of adapters here. There is a small difference between injecting a date/time library and my proposed approach.
If we offer adapters, at some point in the future, chart.js will end up with a dozen of adapters and the problem of bundle size may not be resolved as people will keep injecting the whole date/time library into chart.js.
So instead of a library, we use standalone functions, e.g. format(), parse() (which are provided by date-fns or any library). We don't have to care about those libraries anymore.

[hiendv]

So why do I keep insisting on date-fns? Because of tree-shaking / function separation and it has the similar APIs with moment.js (the current date/time lib of chart.js)

import { format, parse } from 'date-fns/esm'
// No extra bundle garbage

import format from 'date-fns/format'
import parse from 'date-fns/parse'
// This also works