Four demo apps, covering both integration paths (explicit import vs. Vite plugin) against two different sources of the library:
examples/
local/ # pnpm workspace members — use the library's local source
react-vite-import/ # explicit `installVirtualConsole()` import
react-vite-plugin/ # `virtualConsoleVitePlugin()` injected before the app mounts
published/ # standalone projects — install @codehacks/virtual-console@latest from npm
react-vite-import/ # explicit import, against the real published package
react-vite-plugin/ # Vite plugin, against the real published package
Scripts follow <action>:<flavor>:<environment> — e.g. dev:vite-plugin:published runs the Vite
plugin flavor against the published npm package. Dropping the flavor segment runs both flavors at
once (e.g. build:local builds both local examples).
Listed in the root pnpm-workspace.yaml (examples/local/*), so @codehacks/virtual-console resolves to this repo's own src via workspace:*. Use these while developing the library itself — changes to src are picked up immediately.
pnpm dev:import:local
pnpm dev:vite-plugin:local
# individually...
pnpm build:import:local
pnpm build:vite-plugin:local
# ...or both at once
pnpm build:localNot pnpm workspace members — each has its own pnpm-workspace.yaml (so pnpm treats it as an independent single-package project instead of walking up to this repo's workspace) and its own pnpm-lock.yaml (gitignored, since it's meant to float to whatever latest currently is on npm, not be pinned). They exist to smoke-test the package a real consumer would install, separate from the local workspace-linked build.
pnpm install:published # installs both from the npm registry
pnpm dev:import:published
pnpm dev:vite-plugin:published
# individually...
pnpm build:import:published
pnpm build:vite-plugin:published
# ...or both at once
pnpm build:publishedEach dev/build command installs its own example first, so you don't need to run
install:published before them - it's there for when you just want to refresh both installs
without also running or building anything.
Expect these to occasionally fail to build between a merge and the next npm release. Their source intentionally mirrors the local/* examples (same APIs, same code shape) so they stay meaningful smoke tests — but that means if a PR adds or renames an export, the published/* examples reference it before it's actually published, and tsc will correctly fail with a "no exported member" error until the next version ships. That's real drift, not a workspace bug — check the error message before assuming something's broken. This is also why build:published is intentionally left out of ci.yml (only build:local runs there); run it manually after cutting a release to confirm the published package works.