Blueprint: Consider using date-fns instead of moment in datetime package

[adidahiya]

Lots of benefits listed on this landing page -> https://date-fns.org/.

Looking at https://github.com/palantir/blueprint/issues/245#issue-191786736, moment is a nontrivial part of the current bundle size. I guess the downside would be that many consumers would end up pulling in _both_ date-fns and moment, which defeats some of the bundle savings. Overall though I think it could be a positive change. Thoughts?

Related proposal in react-day-picker: https://github.com/gpbl/react-day-picker/issues/231

[giladgray]

huh i wonder if this could replace any of our DateUtils too?

[llorca]

Sounds good to me, is it considered a breaking change?

[giladgray]

yeah it would be, but this sounds so worth it.

[rcchen]

Corresponding moment thread re: modularization, it's road-mapped for 3.0 but doesn't look like that's happening anytime soon based on the open issues.

We could drop locales?
https://github.com/moment/moment/issues/2373#issuecomment-233293900

[adidahiya]

@giladgray why is it a breaking change

[giladgray]

package dependencies changing significantly (replace moment with date-fns). is that not at least a little breaking?

_edit_ it's not a large break but it could easily affect a consumer's build.

[adidahiya]

moment is not part of our public API. It is not a breaking change.

[adidahiya]

Sorry, I take that back -- we expose it in just one place in the API. It will be slightly breaking iff the format strings differ across Moment and date-fns. See https://github.com/palantir/blueprint/blob/5e57a5e3193b765db34daf29111a117ba0a742cd/packages/datetime/src/dateInput.tsx#L57

[zsherman]

major +1 on this

[bbenezech]

Please, can this issue get higher priority ?
I only use TimePicker from @blueprintjs/datetime
It needs a few dumb helpers from @blueprintjs/datetime/dist/common/dateUtils
Which import * as moment from "moment"; all the things.

Result is 200k minified worth of additional JS to parse landing in the final build.
You can arguably exclude some of the locales part, but you need a Webpack hack for that, that is not mentioned in the docs.

This is not developper friendly and contrasts badly with the rest of the developper experience (which is awesome, to be clear).

[adidahiya]

Well, it's not the highest-priority thing for us right now since there are reasonable workarounds to shave off 145kb. There's one suggested in the thread that @rcchen linked (https://github.com/moment/moment/issues/2373#issuecomment-233293900), which app developers can use _today_ without any blueprint change:

new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/) // Ignore all optional deps of moment.js

I think the right direction is something like what react-day-picker is doing, where moment is an optional dependency. As I mentioned above, the one part of our API where we expose moment is in the date formatting string, which is nearly identical across date-fns and moment __except for locales__. Some users will actually need locale support, so it's best to let them plug in the formatting library of their choice.

Migrating to an optional dependency setup will be a small breaking change which requires a major version bump of the datetime package. We're open to PRs for that change but it might take a little while to iron out what we want to include in 2.0. Relatedly, we're thinking about how we can move quickly in the non-core packages so that we don't need to block everything on @blueprintjs/[email protected]

[adidahiya]

a few updates:

• #309 will address some of the bundle size concerns brought up here
• there's a new datetime library in town... Luxon looks pretty legit, so we might switch to that instead of date-fns

[adidahiya]

Fixed by #2117, which removed the explicit dependency on moment. Apps are free to use date-fns for date formatting if they choose.

TimezonePicker still uses moment-timezone because it provides the most reliable and useful timezone data we could find. Luxon doesn't provide a timezone data object which is necessary for picking from a list of zones.