Merging all .d.ts files with the rollupTypes is a good decision, it also helps Volar to resolve types faster

Dropping umd is LGTM cause there are so many ways to use modules in the browsers without the bundlers, for example https://play.vuejs.org/ is using <script type="importmap"> and <script type="module"> in the browser

https://caniuse.com/es6-module

Dropping cjs build is not good at the moment cause we don't know what the user bundler is, Vite, Webpack, Snowpack, Rspack, Farm, Rolldown, Rollup, Turbopack, esbuild, ... 😶‍🌫️

https://github.com/wooorm/npm-esm-vs-cjs

I'm unsure the problem is what bundler they are using, but rather if they have a bundler to begin with. ESM have been around for a decade, and I have yet to hear about a bundler that doesn't support ESM. I think it's more useful when targeting backend applications which are generally the ones running in CJS environments.

Regardless, after looking a bit at some big libraries it seems Vue & its first-party libs (Pinia, Router, ...) all have CJS and UMD builds available. Same story for some other popular component libraries. So I think it's a good idea to keep support for at least CJS (UMD being less and less useful as you mentioned)

However I'm wondering if the CJS build shouldn't be built separately, and use a different build configuration:

• Single-file output (as in, just the entrypoints)
• No sourcemaps

This would most likely keep the package in reasonable sizes, provide sourcemaps for use with bundlers, and for server-side or very legacy usages CJS would be available. I can try giving a look at going towards this direction.

I've implemented the proposed changes to cjs bundling; package is now sitting at 3.1M, about the same as currently, with esm+maps and single-file cjs w/o maps. 🎉

I've also added a new chunk to isolate ToastProvider and TooltipProvider separately from their namespace; these two are very likely to be used at root-level, while toasts themselves or tooltips may only be used in lazy-loaded chunk(s).

That's an amazing job @cyyynthia ! Loving the approach you had and the results!

Perhaps we need to somehow improve the generated types. It has 1 whole file and causing alot of duplication. This also affect the DX to inspect the component types and find related props/emits/slots/expose and their docs.

To prevent types duplication, vueCompilerOptions.skipTemplateCodegen: true might help?

The only way I found to get rid of these is a super hacky find & replace, and running eslint on it to get it a bit more readable, not sure if it's a great setup though 🤔

• declare type __VLS_([a-z]+)_\d+((.|\n)*?)};\n\n => empty
• __VLS_([a-z]+)_\d+ => __VLS_$1
• Run pnpm exec eslint --no-ignore --rule 'ts/ban-types: off' --rule 'import/no-duplicates: error' --rule 'ts/consistent-type-imports: off' --fix dist/index.d.ts dist/date.d.ts

I haven't checked if it improves the DX of the single-file dts so I don't know if it'll make a difference (unless Vue relies on types having precisely the right name, idk); however I do know that a single .d.ts is faster to resolve, and is 1.8M than the current types output; it'd be really nice to get it to work nicely 🤔

👀 fb372d6