Yunfei He
14d5e5f9ad
* feat(vite)!: don't bundle @vitejs/plugin-vue; compose it explicitly BREAKING: vueTui() no longer includes @vitejs/plugin-vue. Add your own SFC/JSX compiler alongside it — `[vueTui(), vue()]` for SFCs (JSX was already explicit: `[vueTui(), vueJsx()]`). This makes SFC and JSX consistent, matches Vite convention (your framework plugin is visible in the config), removes the "is plugin-vue already bundled?" ambiguity, and keeps @vue-tui/vite focused on the terminal dev server (HMR) + build wiring. The dev plugin already force-client-compiles whichever plugin-vue/plugin-vue-jsx is present (matched by name in configResolved), so user-provided plugins work identically to the previously-bundled one. - index.ts: drop the bundled vue() and the `vue` passthrough option. - package.json: @vitejs/plugin-vue moves from dependencies to devDependencies + an OPTIONAL peerDependency (^6) — optional because JSX (plugin-vue-jsx) and h() users don't need it; the version is still validated when present. Bump 0.1.2 -> 0.2.0. - Update all in-repo SFC configs (examples + fixtures) and the dev/build tests to `[vueTui(), vue()]`; update basic-template's README. vp run ready green (vite suite 129 tests, runtime examples 6). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(vite): use the public [vueTui(), vue()] form in dev tests The decouple migration left the tests on the spread `[...vueTui(), vue()]` while configs/examples/docs use `[vueTui(), vue()]` (Vite flattens the nested plugin array — verified it works in createServer too). Align the tests to the documented consumer form for consistency. Vite suite green (12 files, 28 tests). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(vite): compiler plugin first in order — [vue(), vueTui()] Convention: list the SFC/JSX compiler first and vueTui() last ([vue(), vueTui()] / [vueJsx(), vueTui()]). Order is functionally irrelevant (devPlugin force-compiles whichever plugin-vue/vue-jsx is present by name in configResolved), so this is purely stylistic consistency across configs, examples, fixtures, tests, and docs. Also refresh @vue-tui/vite's own README, which still showed the pre-decouple [vueTui()] form and documented the now-removed `vue` passthrough option. Vite suite green (28 tests, incl. the JSX path). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.7 KiB
1.7 KiB
basic-template
A minimal vue-tui app written with Vue SFC <template> syntax. It is the
canonical reference for wiring up the @vue-tui/vite plugin.
Setup
// vite.config.ts
import { defineConfig } from "vite";
import vue from "@vitejs/plugin-vue";
import { vueTui } from "@vue-tui/vite";
export default defineConfig({
plugins: [vue(), vueTui()],
});
// package.json
{
"scripts": {
"dev": "vite", // in-process terminal dev server with HMR
"build": "vite build", // bundles src/main.ts -> dist/main.js
"preview": "vite build && node dist/main.js",
},
}
Running it (use vanilla vite@8)
This example is a configuration reference. The recommended and proven setup
is vanilla vite@8: npm run dev boots
the app in-process and applies state-preserving HMR as you edit src/app.vue;
npm run build emits a single self-contained dist/main.js.
Caveat inside this monorepo
In the vue-tui monorepo, the vite specifier is overridden to
@voidzero-dev/vite-plus-core (see pnpm-workspace.yaml overrides/catalog).
With that override:
vite buildworks — the production bundle is produced normally, and the workspace build (vp run build) includes this example.vite(dev) does not run the app here — vite-plus-core'sssrenvironment is not a runnable dev environment, so the in-process launcher cannot start the app and the plugin reports[vue-tui] the "ssr" environment is not runnableinstead of crashing. This is a vite-plus-core limitation, not a problem with@vue-tui/vite. To exercise the terminal HMR dev server, run this example outside the monorepo against a plainvite@8install.