The 'standard' for writing a vue component library

[quantix-dev]

Im attempting to write a reusable component library which is full of vue SFCs and built using vite so I can view them in storybook.

|- \src
|-- src\components
|----src\components\Button.vue
|-- src\app.vue
|-- src\main.ts

main.ts would be the export for the plugin, containing the install() which would then call vue.component() for each component in the components directory similar to @nuxt/kit's addComponentsDir.

How would I go about actually building this as a package so that users can just install the plugin and have all the components + typings.
I mentioned @nuxt/kit but i'd rather keep these components in vue to minimise as many dependencies as possible.

I've got to a point where the plugin exists, and all of my components register when I use the plugin but I have no typings which makes the DX horrible.

Is there any starter template for these type of component libraries / examples I can look at?

[LinusBorg]

I have this starter template: https://github.com/LinusBorg/vue-lib-template

It's a bit overengineered as a monorepo with a playground app and vitepress docs as separate packages. But converning the build setup, types etc. you can look into the /packages/lib directory and will find a good starting point.

[quantix-dev]

Thanks, looks quite similar to the setup I have. How do you get typings for the components in the playground/places you import them? Is there a part of the build-step i'm missing where it creates the component types

[LinusBorg]

Here's where I build the lib's type for production.

https://github.com/LinusBorg/vue-lib-template/blob/ffabdf3212cfdd57056428dbf7eca0105719c19a/packages/lib/package.json#L32

Also check the other options in package.json for the correct exports of those types.

The playground app doesnt rely on those as its vite config aliases the lib package directly to the lib's src entrypoint during dev, so we don't need to build the lib for the playground.

[pavi2410]

Thanks, @LinusBorg! I was looking for an overengineered template like yours 😁

[johnwc]

@LinusBorg fast forward to today, does your template still work the same? Does it produce type definitions for downstream projects to use during development? Does it allow for a project to just use one component out of lets say 10 in the library, and have the rest not imported via tree shaking?

[derwaldgeist]

I am also wondering what the best way of creating a re-usable library is. Will look into this repo, thanks for sharing! And citing @johnwc, I'd also like to know if this approach supports tree-shaking?

[skirtles-code]

I created a scaffolding tool similar to create-vue but for libraries. It shares a lot of similarities with LinusBorg's template. Docs at:

• https://skirtles-code.github.io/create-vue-lib/

Any tool that creates ESM builds should support treeshaking, assuming you export individual components. If you rely on a plugin to register all components globally then you won't get treeshaking, but that's up to you rather than the build tooling.