RepoPilotOpen in app →

vitejs/vite

Next generation frontend tooling. It's fast!

GO

Healthy across the board

  • ✓Last commit today
  • ✓5 active contributors
  • ✓Distributed ownership (top contributor 41%)
  • ✓MIT licensed
  • ✓CI configured
  • ✓Tests present
  • ⚠Small team — 5 top contributors

Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests

Embed this verdict

[![RepoPilot: GO](https://repopilot.app/api/badge/vitejs/vite)](https://repopilot.app/r/vitejs/vite)

Paste into your README — the badge live-updates from the latest cached analysis.

Onboarding doc

Onboarding: vitejs/vite

Generated by RepoPilot · 2026-05-05 · Source

Verdict

GO — Healthy across the board

  • Last commit today
  • 5 active contributors
  • Distributed ownership (top contributor 41%)
  • MIT licensed
  • CI configured
  • Tests present
  • ⚠ Small team — 5 top contributors

<sub>Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests</sub>

TL;DR

Vite is a next-generation frontend build tool that uses native ES modules in development for instant server start and lightning-fast HMR, and bundles production code with Rolldown (a Rust-based Rollup-compatible bundler). It solves the slow cold-start and HMR performance bottlenecks of webpack-era tools by skipping the bundle step entirely in dev. The monorepo contains the core vite package, the @vitejs/plugin-legacy package for older browser support, and the official documentation site. Monorepo structure: packages/vite contains the core dev server, plugin system, and build pipeline (the main npm package), while packages/create-vite holds the scaffolding CLI and packages/plugin-legacy handles legacy browser transforms. The docs/ directory is a standalone VitePress site with its own package.json and .vitepress/ config, theme components, and build scripts under docs/.vitepress/.

Who it's for

Frontend developers building modern web applications with frameworks like Vue, React, Svelte, or vanilla JS who need a fast dev server and optimized production builds. Plugin authors extending Vite's capabilities and framework authors (like Nuxt, SvelteKit, Astro) who build on top of Vite's dev server and build pipeline also contribute here.

Maturity & risk

Vite is extremely mature and production-ready — it has tens of millions of weekly npm downloads, a robust CI pipeline defined in .github/workflows/ci.yml, and active development with regular releases tracked via CHANGELOG files. The monorepo uses changesets for versioning, has extensive TypeScript coverage (~2.4M TS LOC), and is backed by VoidZero/Evan You's team with multiple active maintainers.

Low risk for production use: the project has multiple maintainers at VoidZero, a public security policy at .github/SECURITY.md, and Renovate-based dependency updates via .github/renovate.json5. The main transition risk is the ongoing migration from Rollup to Rolldown as the production bundler — this is a significant architectural shift that could introduce subtle behavioral differences in edge cases. The @vitejs/plugin-legacy package depends on @babel/core and terser, adding non-trivial transitive dependencies.

Active areas of work

The most significant active work is the migration from Rollup to Rolldown as the underlying bundler — the README explicitly references rolldown.rs. The docs site uses vitepress@^2.0.0-alpha.17, indicating active VitePress v2 adoption. The CI workflow in .github/workflows/ecosystem-ci-trigger.yml shows active integration testing with the broader Vite ecosystem.

Get running

git clone https://github.com/vitejs/vite.git cd vite

Install pnpm if needed: npm install -g pnpm

pnpm install

Build all packages

pnpm run build

Start the docs dev server

cd docs && pnpm run docs

Or run the Vite package in dev mode

cd packages/vite && pnpm run dev

Daily commands:

Docs dev server:

cd docs && pnpm run docs

Docs production build:

cd docs && pnpm run docs-build

Core Vite package watch mode (from packages/vite):

pnpm run dev

Map of the codebase

How to make changes

For core Vite features (dev server, HMR, plugin hooks): start in packages/vite/src/. For documentation changes: edit markdown files under docs/ and configure via docs/.vitepress/config.ts. For the docs theme/layout components: modify docs/.vitepress/theme/components/ or docs/.vitepress/theme/landing/. For legacy browser support: work in packages/plugin-legacy/. Contributing guidelines are in CONTRIBUTING.md and commit conventions in .github/commit-convention.md.

Traps & gotchas

  1. The docs package.json is separate from the root monorepo — you must cd docs and run pnpm install independently there. 2) Rolldown is still in active development and its behavior may diverge from Rollup in edge cases — don't assume 1:1 compatibility when testing build output. 3) The vitepress@^2.0.0-alpha.17 dependency is pre-stable alpha, meaning docs build can break on alpha version bumps. 4) The oxc-minify package used in docs is from the oxc project and is still experimental. 5) Node.js version compatibility is strict — check .github/workflows/ci.yml for the exact supported Node versions before reporting bugs.

Concepts to learn

  • Native ES Modules (ESM) in the browser — Vite's dev server serves source files as native ESM without bundling, which is the core reason it achieves instant server start — understanding how browsers resolve ESM is essential to understanding Vite's dev mode
  • Hot Module Replacement (HMR) — Vite's HMR uses a WebSocket-based protocol to push granular module updates to the browser without full reload — contributors need to understand the HMR API and boundary propagation to work on the dev server
  • Rollup Plugin Interface — Vite's plugin system is a superset of Rollup's plugin hooks, meaning all Vite plugins must conform to Rollup's hook lifecycle (resolveId, load, transform, etc.) — this is non-obvious if you haven't used Rollup directly
  • Dependency Pre-bundling with esbuild — Vite uses esbuild to pre-bundle node_modules into single ESM files at server start, converting CJS modules and reducing the number of browser requests — this is why the first server start has a brief delay and why .vite/deps/ appears in projects
  • Content-Hash Based Cache Invalidation — Vite appends content hashes to module URLs for cache busting in both dev (ETags) and production (filenames) — understanding this is critical when debugging stale module issues or unexpected cache behavior
  • Rolldown (Rust-native Rollup-compatible bundler) — Rolldown is the new Rust-based bundler replacing Rollup in Vite's production build — it aims for Rollup API compatibility while being dramatically faster, and its integration is the biggest ongoing architectural change in the codebase

Related repos

  • rolldown-rs/rolldown — Rolldown is the Rust-based bundler that Vite is actively migrating to as its production build engine, replacing Rollup
  • vitejs/vite-plugin-react — Official React plugin for Vite — a companion repo that most React+Vite users will also use
  • vuejs/core — Vue 3 is deeply integrated with Vite (both created by Evan You) and Vite's HMR protocol has first-class Vue SFC support
  • webpack/webpack — Webpack is the primary predecessor and alternative that Vite was explicitly designed to replace for dev server performance
  • evanw/esbuild — esbuild is used by Vite for dependency pre-bundling and TypeScript/JSX transforms in dev mode — a critical internal dependency

PR ideas

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add vitepress-plugin-llms llms.txt output validation to CI workflow

The repo uses vitepress-plugin-llms (^1.12.1) in its docs dependencies, which generates llms.txt files for LLM consumption. There is no existing CI step in .github/workflows/ci.yml or any other workflow that verifies the generated llms.txt output is valid, non-empty, and correctly structured after a docs build. Adding this check would prevent regressions in AI-readable documentation and validate the plugin integration is working as expected — a concrete, testable artifact that is currently unverified.

  • [ ] Inspect .github/workflows/ci.yml to find where docs-build is run (or add it if missing)
  • [ ] After the vitepress build step, add a shell step that checks for the existence and non-zero size of docs/.vitepress/dist/llms.txt and docs/.vitepress/dist/llms-full.txt
  • [ ] Add a simple grep/assertion to confirm key pages (e.g. 'Getting Started', 'Config') appear in the llms.txt output
  • [ ] Open PR updating .github/workflows/ci.yml with the new validation step and document the rationale in the PR description

Add dedicated blog post for Vite 5 announcement to match existing pattern in docs/blog/

The docs/blog/ directory contains announcement posts for Vite 2 (announcing-vite2.md), Vite 3 (announcing-vite3.md), Vite 4 (announcing-vite4.md), and Vite 4.3 (announcing-vite4-3.md), but there is no announcing-vite5.md or announcing-vite6.md file visible in the file listing. The docs/_data/blog.data.ts data loader presumably sources these files for the blog index (docs/blog.md). A missing announcement post means the blog index is incomplete and users cannot find release notes through the docs site. Contributing the missing announcement post following the established file naming and frontmatter conventions completes the historical record.

  • [ ] Read docs/_data/blog.data.ts to understand how blog posts are discovered and what frontmatter fields are required (e.g. date, title, author)
  • [ ] Review existing posts like docs/blog/announcing-vite4.md and docs/blog/announcing-vite4-3.md to understand the structure and tone
  • [ ] Create docs/blog/announcing-vite5.md (and/or announcing-vite6.md if applicable) with accurate release highlights sourced from the Vite changelog/GitHub releases
  • [ ] Verify the new post appears correctly in docs/blog.md by running npm run docs locally and checking the BlogIndex component renders it
  • [ ] Ensure any images or assets referenced in the post are added under the appropriate docs/ public assets path

Extract SponsorBanner and AsideSponsors sponsor-fetching logic into a shared composable alongside sponsor.ts

The docs/.vitepress/theme/composables/sponsor.ts composable exists, but there are two separate components — docs/.vitepress/theme/components/AsideSponsors.vue and docs/.vitepress/theme/components/SponsorBanner.vue — that likely both deal with sponsor data. If either component duplicates sponsor-fetching, filtering, or formatting logic that already lives (or should live) in sponsor.ts, this is a clear refactoring opportunity. Centralising all sponsor logic in the composable reduces duplication, makes it easier to update sponsor tiers or API endpoints in one place, and improves testability. This is a self-contained, low-risk refactor ideal for a new contributor.

  • [ ] Read docs/.vitepress/theme/composables/sponsor.ts to understand

Good first issues

  1. The docs/.vitepress/theme/components/SupportedVersions.vue component likely has hardcoded version data — it could be refactored to fetch from the npm registry dynamically. 2) The docs/.vitepress/inlined-scripts/banner.js is a minified inline script with only a .d.ts type stub — adding proper source comments or a build step to generate it from readable source would improve maintainability. 3) The packages/plugin-legacy lacks visible test files in the top-60 file list — adding integration tests for specific legacy transform edge cases (e.g., dynamic imports, top-level await polyfilling) would directly improve reliability.

Top contributors

Recent commits

  • 7c3a61f — docs(create-vite): list react-compiler templates in README (#22347) (grzdev)
  • 0420c5d — docs: mention native config loader in CLI options (#22348) (grzdev)
  • 2151f70 — docs: explain mergeConfig skips null/undefined (#22325) (imxv)
  • 0c162e9 — refactor: show direct path type in bad character warning (#22339) (bluwy)
  • 672c962 — fix(deps): update all non-major dependencies (#22334) (renovate[bot])
  • 3b51e05 — chore(deps): update dependency tsdown to ^0.21.10 (#22333) (renovate[bot])
  • 640202a — docs: update evan's x handle (yyx990803)
  • 86aee62 — chore(deps): update transitive packages to fix npm audit alerts (#22316) (sapphi-red)
  • 30028f9 — fix(glob): align hmr matcher options with glob enumeration (#22306) (shulaoda)
  • a190035 — release: create-vite@9.0.6 (sapphi-red)

Security observations

  • Medium · Pre-release/Alpha Dependency in Production Documentation — package.json (docs). The project uses 'vitepress': '^2.0.0-alpha.17', which is an alpha pre-release version. Alpha software may contain unpatched security vulnerabilities, breaking changes, or unstable behavior. Pre-release packages often receive less security scrutiny than stable releases. Fix: Upgrade to a stable release of VitePress when available, or pin to a specific alpha version with a lock file to avoid unexpected updates. Monitor the VitePress changelog for security advisories.
  • Medium · Wildcard Version Ranges Allow Potentially Vulnerable Dependency Versions — package.json (docs). Multiple dependencies use caret (^) version ranges (e.g., '@iconify/vue': '^5.0.0', 'vue': '^3.5.33', 'feed': '^5.2.1', 'vitepress-plugin-llms': '^1.12.1'), which allow automatic minor and patch updates. This means a compromised or vulnerable minor/patch release could be automatically pulled into the project without explicit review. Fix: Consider using exact version pinning or a lock file (package-lock.json / pnpm-lock.yaml) committed to the repository to ensure reproducible, auditable builds. Regularly audit dependencies with 'npm audit' or equivalent.
  • Medium · Third-Party Plugin Dependencies with Broad Version Ranges — package.json (docs). Dependencies such as 'vitepress-plugin-llms', 'vitepress-plugin-graphviz', and 'vitepress-plugin-group-icons' are community/third-party plugins with caret version ranges. These packages are less scrutinized than core ecosystem packages and could introduce supply chain risks if their registries or maintainer accounts are compromised. Fix: Audit third-party plugins for security, verify their npm provenance, pin to exact versions, and regularly check for updates or security advisories. Consider using 'npm audit' and tools like Socket.dev or Snyk for supply chain monitoring.
  • Low · External Content Loading via iframe in Documentation Theme — docs/.vitepress/theme/live/VideoIframe.vue. The file 'docs/.vitepress/theme/live/VideoIframe.vue' suggests embedding external video content via iframes (likely YouTube). Improper iframe usage without appropriate sandbox attributes or Content Security Policy headers could expose users to clickjacking or malicious content from embedded third parties. Fix: Ensure iframes include appropriate 'sandbox' attributes to restrict capabilities. Implement a Content Security Policy (CSP) header that explicitly whitelists allowed frame sources (e.g., 'frame-src https://www.youtube.com'). Add 'referrerpolicy' attributes as appropriate.
  • Low · Missing Security Headers Configuration for Documentation Site — docs/.vitepress/config.ts. Based on the file structure, there is no visible configuration for HTTP security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Permissions-Policy) for the VitePress documentation site. Without these headers, the site may be vulnerable to clickjacking, MIME sniffing, and cross-site scripting attacks. Fix: Configure security headers via VitePress's server configuration or the deployment platform (CDN/hosting). At minimum, implement: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and Strict-Transport-Security.
  • Low · External Resource Loading from Third-Party CDNs — README.md. The documentation site references external resources (SVG logos from vite.dev, badge images from img.shields.io, npm CDN). Loading resources from third-party domains introduces dependency on those services' availability and integrity. Compromised third-party CDNs could serve malicious content. Fix: Where feasible, self-host critical assets. Implement Subresource Integrity (SRI) hashes for externally loaded scripts and stylesheets. Use a strict Content Security Policy to limit which external domains can serve resources.
  • Low · Potential XSS Risk via Markdown Rendering with External Plugins — undefined. The use of 'markdown-it-image-size' and 'vitepress-plugin-graphviz' extends the Markdown renderer. If user-controlled content Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

Where to read next

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.

GO · vitejs/vite — RepoPilot Verdict