Shipping a Vue Library Without a Build Step

Most libraries ship a second copy of themselves

A typical component library has two versions of its code: the source you edit and a compiled bundle in dist/ that you publish. Keeping them in sync is a job of its own, with a bundler config, declaration files, and the occasional bug that only exists in the build.

UI Vintage skips the second copy. The npm package contains the .vue and .ts files as they are written, and the Nuxt module tells each app to compile them like its own code.

What you get for free

The obvious win is less tooling. The less obvious one is that the library behaves exactly like app code, because it is compiled by the same tools with the same settings.

Tailwind scans the library's templates directly, so every utility class a component uses ends up in the app's stylesheet. Vite tree-shakes per subpath import, so a page that only uses a button never loads the date picker.

npm install @brumaombra/ui-vintage
npx nuxi module add @brumaombra/ui-vintage

The tradeoffs are real

The strongest argument against this approach is that it ties the library to its framework. A compiled bundle could, in theory, run in any Vue app. A source package needs the toolchain it was written for, which here means Nuxt.

There is also a version contract to keep. Because apps compile the source, a library update can surface a type error in the app's build that a prebuilt bundle would have hidden. That is arguably a feature, but it does mean releases need a typecheck before they ship.

For a library whose only consumers are Nuxt apps, the trade is easy to accept. The point is not that build steps are bad. It is that a build step is code too, and the cheapest code to maintain is the code you don't need.