Just an observation - the description states that this is a lightweight calendar library, but bundlephobia reports it's actually pretty large compared to other dependency free date pickers out there.
If you could treeshake stuff away, then it'd be fair to state it's lightweight, otherwise I think it's a bit misleading to developers actually looking for a lightweight date picker IMO. Or is bundlephobia misreporting the size?

I think that it would be fair to say it isn't exactly lightweight. That wording was specifically applied for versions before v1.0.0-beta.0 that I never really revisited, so I will definitely revisit that.
A couple of points to note:
v-calendar supports that the others don't. Not saying that is a bad thing at all, but something to consider.One tip is to just import the Calendar component itself and ignore the date picker completely. I know lots of people who do that just because they want to use the attributes.
I would like to explore trying to use async components, especially for the using popovers for anything. However, I've experienced some bugs with that approach that still need to be worked out.
For now, just updated the site wording to 'modern and flexible' :)
Would at least be possible to split the umd minified version (https://unpkg.com/[email protected]/lib/v-calendar.umd.min.js) without poper and styles? eg. v-calendar.umd.min.js, v-calendar.umd.all.min.js Similiar uproach is done in tippyjs where poper is not included, but required and styles are only in .all.min.js.
That would save a few kbs, when served via cdn
Most helpful comment
Would at least be possible to split the umd minified version (https://unpkg.com/[email protected]/lib/v-calendar.umd.min.js) without poper and styles? eg.
v-calendar.umd.min.js,v-calendar.umd.all.min.jsSimiliar uproach is done in tippyjs where poper is not included, but required and styles are only in .all.min.js.That would save a few kbs, when served via cdn