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>
36 lines
1.5 KiB
TypeScript
36 lines
1.5 KiB
TypeScript
// SEQUENTIAL: mutates globalThis.__VT_TEST_STDOUT__ (a process-global frame capture
|
|
// seam) and starts a live Vite dev server; can't run concurrently with the other dev
|
|
// tests. configFile:false + inline plugins — see dev.sequential.test.ts for the reason.
|
|
import { test, expect, afterEach } from "vite-plus/test";
|
|
import { fileURLToPath } from "node:url";
|
|
import { createServer, type ViteDevServer } from "vite";
|
|
import vueJsx from "@vitejs/plugin-vue-jsx";
|
|
import { vueTui } from "../src/index.ts";
|
|
import { capture, waitFor } from "./helpers.ts";
|
|
|
|
const root = fileURLToPath(new URL("./fixtures/jsx", import.meta.url));
|
|
let server: ViteDevServer | undefined;
|
|
|
|
afterEach(async () => {
|
|
await server?.close();
|
|
server = undefined;
|
|
delete (globalThis as Record<string, unknown>).__VT_TEST_STDOUT__;
|
|
});
|
|
|
|
// Regression: vueTui() force-client-compiled only its OWN @vitejs/plugin-vue, never a
|
|
// user-added @vitejs/plugin-vue-jsx. So in the dev SSR module runner the .tsx compiled
|
|
// in SSR mode and the terminal (client) renderer produced a BLANK frame — silently, no
|
|
// error. The fix force-client-compiles every vite:vue / vite:vue-jsx plugin in the set.
|
|
test("JSX (.tsx) components render in the in-process dev server", async () => {
|
|
const read = capture();
|
|
server = await createServer({
|
|
root,
|
|
logLevel: "silent",
|
|
configFile: false,
|
|
plugins: [vueJsx(), vueTui({ entry: "/src/main.tsx" })],
|
|
});
|
|
await server.listen();
|
|
await waitFor(read, "JSX-LABEL");
|
|
expect(read()).toContain("JSX-LABEL");
|
|
});
|