Can tsdown does bundleless Vue SFC files, like mkdist?

[MengLuoRJ]

Can tsdown just copy .vue file and generate .vue.d.ts type file when build Vue SFC files?

This approch usually used in Vue UI components package, make .vue files not be bundled, ship them as it is, then let the comsumers process, like runtime files.

This was done by a bundler(rollup) + a copyer(mkdist), like what unbuild does. Which also the same way processed in the nuxt-module-builder.

I tried the Unbundle Mode, but it only promised the source module structure, still compiled/bundled the vue files into js files.

[Kxrma47]

unbundle preserves output module structure; it is not a pass-through mode for Vue SFCs. The official Vue recipe says unplugin-vue compiles .vue files to JavaScript, while dts: { vue: true } uses rolldown-plugin-dts/vue-tsc for declarations: https://tsdown.dev/recipes/vue-support.

For source-distributed SFCs, copy them separately instead of making them transformed entries:

export default defineConfig({
  entry: ['src/index.ts'],
  dts: { vue: true },
  copy: {
    from: 'src/**/*.vue',
    to: 'dist',
    flatten: false,
  },
})

copy deliberately bypasses Rolldown transforms and preserves directories with flatten: false: https://tsdown.dev/options/copy. Ensure the copied .vue files are not also entry points if you do not want corresponding compiled JS, declare vue as a peer dependency, and point package exports at the copied SFC paths. This gives the mkdist-style source distribution; unbundle alone cannot.

[MengLuoRJ]

Hi, thanks for your reply.
The copy did copy the files, but then the .vue.d.ts files wouldn't be generated.
The way like @nuxt/ui did, they usually ship the .vue with the .vue.d.ts files, that's my really wanted.

[Kxrma47]

Right—copy only preserves the SFC source; it never runs declaration generation. Combine it with tsdown's Vue DTS pipeline:

import { defineConfig } from 'tsdown'
import Vue from 'unplugin-vue/rolldown'

export default defineConfig({
  entry: ['src/index.ts', 'src/**/*.vue'],
  platform: 'neutral',
  plugins: [Vue({ isProduction: true })],
  dts: { vue: true },
  copy: [{ from: 'src/**/*.vue', to: 'dist', flatten: false }],
})

pnpm add -D unplugin-vue vue-tsc

copy keeps the raw .vue files, while dts: { vue: true } invokes the Vue-aware declaration path. Ensure each component is exported by src/index.ts (or remains an entry) and map package exports to the copied .vue file with types pointing to its generated declaration. This is the documented tsdown setup: https://tsdown.dev/recipes/vue-support

[Navesz]

Yes, but not with unplugin-vue. Use two configs: one builds the TS files and leaves the .vue imports alone, and the other only emits declarations for each SFC.

import { defineConfig } from 'tsdown'

export default defineConfig([
  {
    // JS + .d.ts for the TS files; `.vue` imports stay as they are
    entry: ['src/**/*.ts'],
    unbundle: true,
    platform: 'neutral',
    deps: { neverBundle: [/\.vue$/] },
    dts: { vue: true },
    copy: [{ from: 'src/**/*.vue', to: 'dist', flatten: false }],
  },
  {
    // declarations only, one X.vue.d.ts per SFC
    entry: { '*.vue': 'src/**/*.vue' },
    platform: 'neutral',
    dts: { vue: true, emitDtsOnly: true },
  },
])

My test source had src/index.ts, src/utils/format.ts, src/components/MyButton.vue (which imports ../utils/format) and src/components/form/MyInput.vue. After the build, dist contained exactly these 8 files, and I got the same result on 3 builds in a row:

index.js, index.d.ts           // both keep: import MyButton from "./components/MyButton.vue"
utils/format.js, utils/format.d.ts
components/MyButton.vue        // copied source
components/MyButton.vue.d.ts
components/form/MyInput.vue
components/form/MyInput.vue.d.ts

Why each piece is there:

• The '*.vue' key. In an object entry key, * is replaced with the matched path minus its extension (docs, entry.ts). That makes the entry name components/MyButton.vue. The dts plugin then names the declaration chunk ${name}.d (generate.ts). When I used a plain entry: ['src/**/*.vue'] instead, I got dist/MyButton.d.ts and dist/form/MyInput.d.ts.
• emitDtsOnly removes the non-declaration chunks (README), and tsdown forwards dts options to the plugin (rolldown.ts). In this mode the plugin's pre transform swaps each module's code for export {} (generate.ts). That is probably why adding unplugin-vue to this config broke my build with At least one <template> or <script> is required in a single file component.
• deps.neverBundle: [/\.vue$/] keeps the .vue imports external. Without it, the build fails with PARSE_ERROR / Unexpected JSX expression on the SFCs.
• unbundle with src/**/*.ts keeps dist/utils/format.js around. The copied MyButton.vue still imports ../utils/format, so that file has to exist in dist. If src also contains ambient .d.ts files (a shims-vue.d.ts, say), that glob emits them into dist too; entry: ['src/**/*.ts', '!src/**/*.d.ts'] leaves them out.

About the config in the previous reply: it compiles the SFCs to components/MyButton.js and MyButton.d.ts, with no .vue.d.ts at all. Its dist/index.js imports a hashed chunk (./MyButton-<hash>.js) and ./components/form/MyInput.js, so nothing uses the copied .vue files.

Who needs the .vue.d.ts files. I ran npm pack, installed the tarball in a consumer project and passed wrong props from a .vue file and a .ts file (tsc only checks the .ts one):

Consumer check	with .vue.d.ts	without
vue-tsc --noEmit	errors reported	errors still reported
tsc, skipLibCheck: false	errors reported	TS2307 for ./components/MyButton.vue in dist/index.d.ts
tsc, skipLibCheck: true	errors reported	exit 0, wrong props not reported

So the declarations matter for consumers who type-check with plain tsc. For deep imports, this exports entry resolved the types with both tsc and vue-tsc, including vue-lib/components/form/MyInput.vue:

"./components/*.vue": {
  "types": "./dist/components/*.vue.d.ts",
  "default": "./dist/components/*.vue"
}

Tested with tsdown 0.23.0, rolldown 1.2.8, rolldown-plugin-dts 0.28.5, vue 3.5.42, vue-tsc 3.3.11, TypeScript 5.9.3 and Node 24.13.0 on Windows 11. unplugin-vue 7.2.0 was only used in the variants that failed. I did not test watch mode, TypeScript 7 or tsgo, or older tsdown versions. I also did not bundle the shipped .vue files in a real consumer app; they still contain lang="ts", so the consumer's bundler has to compile them.

[Kxrma47]

You're right, and thanks for testing the complete package-consumer path. My previous unplugin-vue configuration compiles the SFC entries and therefore does not produce the requested source .vue plus adjacent .vue.d.ts layout.

The two-config approach is the correct one here: copy the raw SFCs in the TS/unbundle build, then use the keyed '*.vue' entry with dts: { vue: true, emitDtsOnly: true } for declaration-only output. The deps.neverBundle: [/\.vue$/] detail is also necessary to preserve imports to the shipped SFCs.

I withdraw the earlier configuration; your answer addresses the original requirement more accurately.