![\"vp](\"https://janmichalek.com/_next/static/immutable/media/vp-create.18kdug08_k747.webp\")
Jan Michálek
\nOne project had 47 development dependencies, seven config files, and a Markdown file explaining to the agent how to run everything. At 2 a.m., I was debugging a difference between local checks and CI. The code was done; the tooling around it wasn't. After three weeks with Vite+ across four projects, I have a simple rule for new Vite apps: put it in the first prompt I give the AI.
\nvp create, then verify its work with vp check, vp test, and vp build.vp migrate as the start of a migration. I still review the diff, tests, and build behavior.My commands were spread across ESLint, Prettier, TypeScript, a test runner, and package.json scripts. When I let an agent into the project, its first job was figuring out which command was the right one. I wrote instructions to explain that. Now I had another file to maintain. Excellent time saver, right?
It wasn't just the number of files. Once, my local setup and CI checked a generated file differently. The agent saw one result; the pipeline saw another. Faster component generation doesn't fix that.
\nVite+ brings everyday tasks under vp: Vite for development and builds, Vitest for tests, Oxlint and Oxfmt for checks, tsdown for libraries, and Vite Task for tasks. You can keep their configuration in vite.config.ts. You still have package.json, tsconfig, and, depending on the project, framework configuration. “One file for absolutely everything” would look good on a banner and bad in a real repo.
For a React app, these are the commands I need after creating the project:
\nShell
\n1vp create vite -- --template react-ts\n2cd project-name\n3vp install\n4vp dev\n5vp check\n6vp test\n7vp build
The commands above assume vp is available globally. A global install is optional; you can also run Vite+ as a local dependency through a package manager. vp install uses the package manager selected for the project, so Vite+ doesn't replace npm or pnpm.
Creating a project with vp create.
\nThe Vite+ docs include a prompt for AI assistants. It's a useful starting point, but I adapt it to the project. My goal is concrete: the agent should use Vite+ to set up the app and not quietly abandon it after generating the first page.
\nText
\n Create a new React + TypeScript app on Vite using Vite+.\nFirst read the current `vp create` guide and run `vp help create`.\nInspect the target directory and do not overwrite existing files.\nChoose the current stable Vite+ release and one package manager.\nCreate the project with `vp create` using the React + TypeScript template.\nKeep its single lockfile. Do not add another linter or formatter\nunless there is a specific reason.\nAfter setup, run `vp install`, `vp check`, and relevant tests\nwith `vp test`, and run a production `vp build`. Add a test for the\nbehavior you implemented. If a check fails, fix the cause and rerun it.\nIn your final report, list the Vite+ version, commands, and actual results.
I don't require a global install via curl in every project. For a one-off setup, something like npx --package=vite-plus@1.3.0 vp create is enough; in an established project, the agent can run the local CLI through the selected package manager. I don't ban create-vite, either: vp create vite uses that template. What matters is that the agent follows the intended setup and keeps one consistent toolchain.
When I gave an agent free rein, I ended up with both Prettier and Oxfmt, three lockfiles, and unreliable CI. Banning a second formatter and requiring one lockfile aren't aesthetic preferences. They're two mistakes I don't want to clean up again.
\nAfter changing code, I run vp check. It checks formatting and lint; it checks TypeScript when both typeAware and typeCheck are enabled in the configuration. A new project created with vp create enables them by default. In an existing project, I verify that setting instead of assuming a green result also means the types are sound.
Here's the difference from my old workflow:
\nShell
\n1# Before: it depended on each project's scripts.\n2npm run format:check\n3npm run lint\n4npm run typecheck\n5\n6# Now, in a project with the corresponding Vite+ configuration.\n7vp check
vp check --fix can repair some findings automatically. After that, I read the diff and run the check again. A green lint result still doesn't tell me whether the app does the right thing. I need vp test for behavior and vp build to verify the application builds.
I also put that rule in the repo's agent instructions. When I return to a project a week later, a new agent won't remember yesterday's chat. The repo still knows its commands.
\nMarkdown
\n 1## Checks before completing a task\n2\n3- After changing code, run `vp check` and fix any errors.\n4- After changing behavior, run the relevant tests with `vp test`.\n5- Before handing off a Vite app, run `vp build`.\n6- Review the diff after automatic fixes.\n7- Report the actual results; don't call a failed run complete.
Local instructions and Git hooks help, but they can be bypassed or disabled. I run the same checks in CI. On an experiment where I let an agent work unattended, human review before merging was still my responsibility.
\nIn a monorepo, CI went from 4 minutes to 50 seconds after I changed the workflow. A pre-commit check dropped from 11 seconds to under 2. Those are results from my projects, not a benchmark comparing Vite+ with another toolchain under identical conditions. Part of the gain comes from what runs and which files it checks; you won't automatically get those CI times with a different configuration.
\n![\"GitHub](\"https://janmichalek.com/_next/static/immutable/media/classic.1ga5hgr103r0d.webp\")
GitHub Actions: the classic toolchain benchmark took 10.441 s.
\n![\"GitHub](\"https://janmichalek.com/_next/static/immutable/media/viteplus.2-ywjv-drgop4.webp\")
GitHub Actions: the Vite+ benchmark took 1.356 s.
\nFor quick checks of changed files, I use vp staged and Git hooks managed with vp hooks. When different projects behave differently, vp toolchain shows me their active versions. vp toolchain --global shows the global installation. That's more useful for debugging than my old method: “I definitely updated it.”
![\"vp](\"https://janmichalek.com/_next/static/immutable/media/vp-staged.2x_40n-pgog9_.webp\")
Checking the staged file with vp staged.
\n![\"vp](\"https://janmichalek.com/_next/static/immutable/media/vp-toolchain.1x699rowz2mdw.webp\")
vp toolchain shows the active tool versions in the project.
\nThere are two things to distinguish in a monorepo. vp run executes a package.json script or a task defined in vite.config.ts, and it can order work according to workspace dependencies. Caching is not enabled automatically for package.json scripts. You can enable it with, for example, vp run --cache build. Tasks defined in vite.config.ts are cached by default. I won't turn my CI timing into a promise that vp run alone makes every build faster.
vp migrate ran on an older monorepo for about 4 minutes. It converted my ESLint, Prettier, and original tsup build setup, and nothing broke in my case. That doesn't mean every migration takes four minutes. You have to compare the result with the old lint, tests, hooks, and build output. Plugins and custom rules may still need manual work.
Another trap is the difference between a built-in command and a project script. vp build runs a Vite app build. vp run build runs the build script from package.json or a task with that name. In a Next.js project, the agent must not assume vp build replaces next build. The same distinction applies to vp dev and vp run dev. Vite+ can work with other templates, but that doesn't change what those commands do.
The third issue is version management. The global vp env can manage Node.js and package managers. I have three projects on three Node versions, and it made switching easier for me; if you don't want that, you can turn it off with vp env off. vp upgrade updates the global CLI, not the local vite-plus package in every project automatically. I wrote that explicitly in my agent instructions because the command name invites the opposite assumption.
Anyone starting a new Vite app with AI doing the setup. The cost of standardizing is small here: choose one toolchain, put the check commands in the repo and CI, and the agent has a clear path from a code change to verification. Across three weeks and four projects, the main benefit for me was that I stopped explaining the basic commands over and over.
\nI wouldn't blindly migrate a large existing app with a working build and test suite. For a framework with its own build, I'd first decide which parts of Vite+ I actually want to use. And if I already had a well documented, fast, stable stack, the promise of “one command” alone wouldn't convince me to replace it.
\nNext time you start a Vite project, put vp create in the first prompt and ask for the outputs of vp check, tests, and the build as part of the definition of done. A screenshot of the finished app is nice. Passing checks tell you more.