React-big-calendar always depends on dayjs code

[TomiBelan]

Check that this is really a bug

• I confirm

Reproduction link

https://gist.github.com/TomiBelan/3f130739f8f5ac5deaecaeec49e904f6

Bug description

React-big-calendar has a runtime dependency on dayjs. If you compile an app using react-big-calendar with webpack, the minified bundle will always contain code from dayjs, even if you use a different localizer. The whole point of pluggable localizers is allowing users to choose which datetime library they want to depend on, so this is kind of unfortunate. The dayjs code is ignored at runtime and it just uselessly bloats the bundle size downloaded and parsed by browsers.

It happens because dist/react-big-calendar.esm.js imports some dayjs plugins, and webpack wasn't able to recognize the plugin code is side-effect-free and safe to remove.

Luckily, dayjs is a very small library. In practice it's not a big deal. This is a low priority issue.

Some ideas

• Revisit the decision in feat: Dayjs localizer #2264 to automatically load dayjs plugins. One fix is to stop doing that, and tell the user which plugins they must load themselves. But it is a compatibility break...
• Another possible idea might be to change dist/react-big-calendar.esm.js so that it imports "dayjs/esm/plugin/foo" instead of "dayjs/plugin/foo". Apparently webpack recognizes the esm version has no side effects. But it might need some RBC build system hackery. dist/react-big-calendar.esm.js should import "dayjs/esm/plugin/foo" but lib/localizers/dayjs.js should still require("dayjs/plugin/foo") like before, in order to not break server-side node.js scripts doing require("react-big-calendar"). (There might be a better way but I'm not all that familiar with node.js's ESM support.)

Expected Behavior

Webpack output bundle should contain dayjs code only if you use the dayjs localizer.

Actual Behavior

Webpack output bundle always contains dayjs code (specifically dayjs plugins).

react-big-calendar version

1.6.9

React version

18.2.0

Platform/Target and Browser Versions

Chrome

Validations

• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
• Make sure this is a react-big-calendar issue and not an implementation issue

Would you like to open a PR for this bug?

• I'm willing to open a PR

[cutterbl]

@TomiBelan Great feedback. I know in the next major upgrade we're exploring a multi package setup, where the localizers are completely separate packages. When I get some time I'll try to look at possibly separating the current localizers from the core Big Calendar code, but that will be a breaking change as well.

[TomiBelan]

Thanks for replying! Hmm, separate packages are an interesting idea but there might be an easier fix:

That "RBC build system hackery" I mentioned might be easier than I thought. I noticed your babel.config.js already replaces lodash with lodash-es for the esm build. I wonder if adding a replacement from dayjs to dayjs/esm would do the trick?

I might try to send a pull request later if needed and if I have time. Though I'm not really sure how would I test it.

[jaredhill4]

Hi, I'm wondering about this, too. As I'm trying to move away from moment altogether and use dayjs instead. So it would be wonderful if there were a way to tree shake the additional localizers from the bundle.

[cutterbl]

@jaredhill4 We're looking at that for our next major release. Come give us your thoughts in the #next channel of our Slack community.