V-calendar: Is there any possibility to reduce bundle size?

[Va1entina]

I really like this plugin. But the bundle size is about 247 KB and it's quite big.
I use components method for import (import DatePicker from 'v-calendar/lib/components/date-picker.umd'). Is there any possibility to reduce bundle size?

[andreasvirkus]

This 3x increase in bundle size _is_ a bit drastic...

Linking to https://github.com/nathanreyes/v-calendar/issues/397 and https://github.com/nathanreyes/v-calendar/issues/314

@nathanreyes I feel this is a pretty critical thing to address for v1 🙏 (which I & many others are super excited for!)

I can try to dig into the build setup next week to cut down on the size. Off the top of my head

• would you be willing to move to rollup? Webpack doesn't support ESModules and whilst vue-cli-service build is convenient, it's not great - at all - for libraries.. There's a vue-cli plugin for that as well
• would it be ok to move popper also to peerDeps? (especially since the inline/Calendar use-case does not need it at all)

[amaury-tobias]

I think part of the "problem" is tailwind, I tried a custom build cleaning the unused styles and the size was reduced a lot, around 60k

[robertguss]

maybe something like https://purgecss.com/ could be utilized? I always use it on my tailwind projects otherwise the bundles are quite large.

[rebz]

+1

[nathanreyes]

So purgecss is actually used on this project but there are some white-listed classes that support configuring different theme colors and calendar attributes at runtime. A lot of that can't be predicted at build time.
https://github.com/nathanreyes/v-calendar/blob/master/.postcssrc.js

It probably could be refactored to require importing separate css files in order to get support for specific colors, but the tradeoff would be an extra bit of work for developers to remember to do that.

Popper.js was added in the version 1 beta to really help the performance and memory overhead with popovers, but unfortunately added quite a bit of size. I'm working on a branch currently to use Popper v2 which should cut down the size even more.

[itpropro]

Thanks for the great work on v-calendar so far! This would really be appreciated. I just use the date picker at one place and it is the biggest part of vendors by far:

I really love the flexibility and the options that v-calendar provides, but in many use cases you just need a small subset of features. Especially with the date picker being a full wrapper around v-calendar there is a lot of overhead.

[rodrigomata]

Having the ability to have the CSS in another file, would not only reduce the bundle size, but will also allow to have a more strict CSP policy, since this plugin inline the styles

[buremba]

We're importing just DatePicker component from the package and it's still 250kb. This is a blocker for us since our app is quite big at the moment, I would love to see the ability to use individual components with rollup support.

[hmaesta]

First of all: not a v-calendar user. We are doing a redesign of our app and looking for a lightweight option – besides v-calendar looks the most complete, the weight was a _no-go_ for us.

---

I believe the first step is adding an optional props that blocks all style imports – since it's optional only developers who want to have control of styles can activate. That way we can "start fresh" and it will be easier to find out what is _really_ useful in real case scenarios.

For example, right on the base there are some styles that I don't think are necessary.

https://github.com/nathanreyes/v-calendar/blob/b1468ddc3d43f068632704de1e974190df0310ee/src/components/Calendar.vue#L785-L789

I understand that the calendar should have consistency, but this adds unnecessary steps for customisation – and removes the consistency of the final project. The developer has to overwrite the class with the app font, instead of "doing nothing", since the natural behavior would be the calendar using document's default font.

Second, Popper is not a villain, but it also should be optional (a plugin maybe?). I understand it brings a lot of benefits, but by default Vue already offers the necessary for a basic integration.

An example using Tailwind CSS:

<div class="relative">
   <button @click="datepicker = true">Calendar</button>

   <transition
      enter-active-class="transition ease-out duration-150"
      enter-class="transform opacity-0 -translate-y-2"
      enter-to-class="transform opacity-100 translate-y-0"
      leave-active-class="transition ease-in duration-150"
      leave-class="transform opacity-100 translate-y-0"
      leave-to-class="transform opacity-0 -translate-y-2">

      <div v-if="datepicker" class="absolute z-10">
         <v-date-picker is-inline/>
      </div>

   </transition>
</div>

Definitely not as good as Popper, but it's a really easy method. For not-complex integrations: why not?

[MartinMalinda]

Browsing through the bundle dist there seems to be way too much lodash code. It seems like code splitting is not working as good as it should, because there's three or so lodash functions being used.

[hmaesta]

25% is definitely an improvement. Nice job, @nathanreyes 👏

[hmaesta]

• 2.1.1: 201.1 kB / 60.9 kB
• 3.0.0-alpha2: 161 kB (-19.9%) / 42.7 kB (-29.8%) 👏

[nathanreyes]

I think I'll close this issue now since I've trimmed it about as much as I can by removing Tailwind and refactoring other things. Vue 3 build uses Rollup for builds so I was pleasantly surprised with those results.

That is about as much as I can do at the moment.