Library Size

[ccurtin]

First of all, really nice job! Exactly what I was looking for.

I just have a little concern with the size of the library, do you know why it's over 100KB when compressed? Are you utilizing another(larger) library?

Thanks!

[ccurtin]

Never mind, looks like it's because of moment-timezone

[lostpebble]

Yea its massive. Surely there is a way to make it smaller? Do we need all the locales that come with moment-timezone? Isn't that mostly for language stuff.

This is a bit ridiculous:

Like what the heck is that data/packed thing? Its like 5 times the size of the original moment library!

Never mind: moment/moment-timezone#697

I see it is all the timezone data for the past however many years. Damn timezones... we should just get rid of them altogether (on this planet, I mean - not the library).

[lostpebble]

Good news for anyone using webpack and not using the timezone aspect of this library.

I put this in my webpack plugins (basically replaces moment-timezone with regular moment and removes all locales):

plugins: [
      new webpack.NormalModuleReplacementPlugin(
        /moment-timezone/,
        'moment'
      ),
      new webpack.IgnorePlugin({
        contextRegExp: /moment/,
        resourceRegExp: /^\.\/locale$/,
      }),
    ],

Much nicer:

[harrisiirak]

@lostpebble thanks for bringing this up! We could possibly remove moment-timezone dependency in the future (date-fns is rather lightweight and sane library I've been using instead of moment monolith lately). Therefore I'm not closing this issue atm.

[ghost]

Day.Js is a nice alternative to me with etc support

⏰ Day.js 2KB immutable date library alternative to Moment.js with the same modern API

https://github.com/iamkun/dayjs

[lostpebble]

@xxyuk the biggest issue is timezone support, which Day.Js doesn't seem to have: iamkun/dayjs#46

Supporting timezone is always going to be a massive amount of data because of the fact that every nation in the world has pulled a random number out of their ass to define an irrelevant time that they think the clock should display when the sun rises and sets (sometimes multiple numbers and the can be different at multiple times during the year too...).

Day.Js seems to have a better way of dealing with locales though, and the rest of the library is smaller as well I think. So its a good choice if there wasn't any need for timezone support.

[santigimeno]

I think using something like https://github.com/yurikuzn/moment-timezone-data-build with moment-timezone might be acceptable for many.

wrt date-fns, it's very nice but last time I checked the tz support wasn't there. Is it now available?

[chiptus]

maybe just let the user supply instances for moment himself?

[tjk]

I have a port to luxon here: https://github.com/tjk/cron-parser/tree/luxon

Can it help this library at all?

[harrisiirak]

@tjk looks nice... but isn't ´luxon´ even heavier (judging this based on the package size) than ´moment-timezone´?

[tjk]

moment-timezone depends on moment, though. See here:

• https://bundlephobia.com/result?p=luxon@1.22.0
• https://bundlephobia.com/result?p=moment-timezone@0.5.27

[harrisiirak]

With new cron-parser@3.0.0 (switched from moment-timezone to luxon, thanks @andytson) there are some good news, bundle size is reduce around 4x.