Vitamin 2.0 is an opinionated Vite starter with the testing already set up

A starter template, and what that means

Vitamin is described in one line as an opinionated Vite starter template, and the README is titled Vitamin 2.0 with a note that the previous version is available on the v1 branch.

That framing sets expectations properly. This is not a framework and not a component library. It is a repository you copy, with a set of choices already made about how a React and TypeScript project is built, tested, linted and formatted. The value is the elimination of a week of setup decisions, and the cost is that you inherit those decisions.

What the template does not include is as informative as what it does. There is no component library in the dependency list, no styling system beyond Tailwind, and no state management beyond React Query. The feature list in the README is a list of tools: Vite 6 with React 19, TypeScript 5 and absolute imports through vite-tsconfig-paths, Tailwind CSS v4 for styling, Biome V2 for linting, formatting and automatic import sorting, Vitest 3 with Testing Library 16 for unit and integration tests, and Playwright 1.52 for end to end tests.

Those are the choices an opinionated template makes for you. The first page of your new application will have a router, a query client and a validation library wired in, and it will not have a button component.

The project is MIT licensed, the primary language is TypeScript, the default branch is main, the last push was on 2026-04-06, and the repository has no GitHub releases, so the template is versioned by its branches rather than by tags. The homepage is a deployed instance at vitamina.netlify.app.

Getting a copy without the template's git history

There are two ways to start, and the README gives both.

The first is to use the repository as a GitHub template, which is the standard path and which gives you a new repository with the files, and a fresh commit history of your own.

The second is degit, which clones the project to your machine with an empty git history:

npx degit wtchnm/Vitamin#main my-app

The #main suffix selects the branch, and my-app is the target directory. degit is the tool Rich Harris wrote for exactly this problem, and it is the right choice when you want the files without the upstream history and without a GitHub account step.

Then the dependencies:

pnpm install

pnpm is the package manager, and the package.json pins it as packageManager [email protected], so a corepack aware setup will use the right version automatically. The lockfile is a pnpm-lock.yaml, and the pnpm section in the package.json is more than boilerplate. It has an ignoredBuiltDependencies entry for cypress and an onlyBuiltDependencies list covering @biomejs/biome, @tailwindcss/oxide, esbuild and msw. That is the mechanism by which pnpm decides which packages are allowed to run install scripts, and the list is short because most packages in this stack no longer need to run anything at install time.

One artifact of the v1 history is visible here. Cypress appears in ignoredBuiltDependencies, and the README's Playwright bullet links to the Cypress documentation site, which is a copy and paste leftover from when the template used Cypress for end to end tests. The package.json itself has no Cypress dependency, and the e2e scripts run Playwright.

Three kinds of test, three different runners

The testing setup is the part of this template that would take the longest to reproduce by hand, and it is split three ways.

Unit and integration tests run under Vitest, with Testing Library for the component level. The package.json shows the environment work: happy-dom is a dev dependency, which is what Vitest uses as a DOM implementation, and msw at 2.12.14 is the mock service worker, configured to put its worker files in the public directory through the msw.workerDirectory setting. So network calls in tests are intercepted at the service worker level rather than with hand written fetch mocks.

End to end tests run under Playwright, with the config in playwright.config.ts at the repository root and the tests directory at the top level. The Playwright configuration is TypeScript rather than JavaScript, which matches the rest of the project.

The distinction in the scripts is worth noting. The test script is plain vitest, so in a terminal it runs in watch mode and reacts to changes. The test:ci script is vitest run, which is the single pass version used in CI. The e2e scripts are playwright test --ui for the interactive runner and playwright test for the headless one, and the ci variant is what the validate command calls.

That gives four distinct commands, and they exist because a developer wants a fast loop locally and a deterministic, single pass run in a pipeline. A template that had collapsed them into one script would have been less useful, and this is the sort of detail that is invisible until you are the one who needs the difference.

What the package.json actually installs

The README's feature list describes categories. The dependency block describes the specifics, and it is worth reading because the runtime dependencies are not the ones a Vite starter ships by default.

The runtime dependencies are @tanstack/react-query at 5.95.2 with its devtools package, react and react-dom at 19.2.4, react-error-boundary at 6.1.1, react-router at 7.13.2, and valibot at 1.3.1.

That is a specific house style. A router, a server state library with devtools, an error boundary and a schema validation library are all present, and all of them are pinned to exact versions rather than ranges, which is a deliberate choice for a template whose whole point is reproducibility. There is no component library, so the visual layer is yours to choose, and no date library, no form library and no global store, which keeps the floor low.

On the tooling side, the dev dependencies cover Biome at 2.4.9, Playwright at 1.58.2, the Tailwind Vite plugin and tailwindcss at 4.2.2, four Testing Library packages, the Vitest coverage provider, happy-dom, msw, typescript at 6.0.2, and vite at 8.0.3.

Compare those numbers with the README and you find the drift. The README says Vite 6, Vitest 3, Testing Library 16, Playwright 1.52 and TypeScript 5, while the manifest installs Vite 8, Vitest 4, Playwright 1.58 and TypeScript 6. The library families are the same, but the major versions have moved, and the README's own Playwright link points at the Cypress documentation site. For a template whose value is that the versions are already right, the manifest is the source of truth and the README is a lagging description of it.

One command to check everything

The script list in the README is short and each entry has a clear job. There is dev to start a development server with hot reload, build to build for production with the output in the dist folder, and preview to serve the production build locally.

The verification scripts are the interesting ones. pnpm test runs the unit and integration tests for files changed according to git, and pnpm test:ci runs all of them. pnpm test:e2e runs the end to end tests with Playwright in its interactive UI mode, and pnpm test:e2e:ci runs them headlessly.

Formatting and linting are unified under Biome. pnpm format runs the Biome formatter over the files, and pnpm lint runs TypeScript and Biome, which in the manifest means tsc -b for the type check and biome check --write --unsafe for linting with automatic fixes.

And then there is validate, which runs lint, test:ci and test:e2e:ci in sequence. That is the command to put in a pipeline, and it is the reason the template can be a template: a new project starts with a working definition of done, and the same command runs on a laptop and in CI.

The dev script is vite --open, which starts the server and opens a browser, and the build script is vite build. The repository layout supports the same split on the config side: vite.config.ts for the bundler, tsconfig.json with tsconfig.app.json and tsconfig.node.json for the TypeScript project references, playwright.config.ts for the end to end runner, and biome.json for the Biome rules. There is also a .vscode/ and a .zed/ directory, so the editor configuration is part of the template rather than something you add later.

What to check before you build on it

There are a few things to settle before this becomes your project's foundation, and none of them are hard.

First, the version drift. The README and the manifest disagree, so read the manifest, and read the lockfile. Since the lockfile is committed, a fresh install gives you the exact dependency graph the template was tested against, and that is a better starting point than a fresh resolution.

Second, the pnpm requirement. The template is pnpm only. pnpm install is the documented step, the packageManager field pins the version, and the pnpm specific sections in the manifest, the ignored and only built dependencies, only take effect under pnpm. A team standardised on npm or yarn will need to translate that configuration, which is more work than it sounds because the build script allow list is part of how the install succeeds.

Third, the scope of the template. React Query, React Router, an error boundary and valibot are already in the project, and if your team would rather choose those later, removing them is easy but the opinions are already expressed in the starter code, which you will inherit whether you like them or not.

Fourth, the v1 branch. The README says the previous version is available there, and for a template that is worth checking before you pick a side, because the difference between a 1.x template and a 2.x template is exactly the kind of thing that is annoying to discover six months in.

And finally, the honest limitation of every starter template. The wiring is solved, the application is not. Vitamin will save you the setup decisions, and it will not save you the architecture, the domain modelling, or the parts of the product that are actually hard. A template that is 200 files of configuration and 5 files of your code is worth using precisely because the ratio is that way round.

Editorial conclusion

Adopt Vitamin if you want a starting point where the toolchain decisions are already made and consistent, particularly the testing split between Vitest, Testing Library and Playwright and the single Biome command that lints and formats. Do not adopt it as a React framework, since it deliberately includes no component library and no data layer, and expect to spend the first hour fixing the version drift between the README and the lockfile. Before you start, read the package.json rather than the README's feature list, since the installed versions are ahead of the documented ones.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. wtchnm/Vitamin on GitHub