vitejs/devtools

1. What this repo is

- This is a pnpm monorepo for the Vite DevTools ecosystem.

- The main product is a developer tooling platform that visualizes Vite/Rolldown internal state, build graphs, messages, terminals, and plugin data.

- The repo is split into reusable packages, feature-specific apps, examples, docs, and automated tests.

2. Primary architecture pattern

- The core design is a node-side plugin/runtime paired with a client-side UI.

- Data is collected in the host process, exposed through RPC/state channels, and rendered in a browser-based UI.

- Several packages follow the same pattern: a node layer gathers data, and an app or client layer renders it.

3. packages/kit: the shared SDK boundary

- packages/kit is the main abstraction layer for plugin authors.

- It defines the public API, types, utilities, and shared-state primitives used by other packages.

- It also contains client-side helpers for remote interaction and node-side helpers for creating devtools plugins from a Vite-style host context.

- Architecturally, this package is the contract layer between integrations and the core UI/runtime.

4. packages/core: the central runtime

- packages/core is the largest and most central package.

- Its node side contains CLI entrypoints, config, diagnostics, HTTPS, WebSocket transport, plugin registration, server startup, and RPC endpoints.

- Its client side contains the main devtools UI built from web components, including docks, command palette, messages, terminals, settings, toasts, JSON rendering, and floating UI.

- It supports both injection into another app and a standalone mode, which is an important deployment boundary.

5. Core data flow

- The node runtime collects diagnostics and runtime state, then publishes it through RPC and socket-based mechanisms.

- The client layer consumes that state and organizes it into dockable panels and views.

- Core’s internal state managers cover commands, docks, messages, terminals, confirmations, keybindings, popups, and persistent view state, which are the main interaction surfaces of the UI.

6. UI system and rendering model

- The core client UI is implemented with a web components / Vue-based component system.

- It has distinct subdomains for:

- dock layout and panel management,

- built-in views like settings/messages/terminals,

- JSON renderers for structured objects,

- floating popovers/tooltips,

- icons and display primitives.

- This makes the UI layer modular: the shell orchestrates layout while specific views render the actual data domains.

7. packages/ui: shared design primitives

- packages/ui is a smaller cross-package UI toolkit.

- It provides reusable visual components, composables, CSS, and UnoCSS configuration.

- This package is a presentation dependency rather than a runtime boundary; it standardizes look-and-feel across the ecosystem.

8. Feature packages: Vite, Rolldown, Self-Inspect

- packages/vite is a Vite-specific surface that exposes Vite environment and metadata info through RPC and renders a dedicated app.

- packages/rolldown is the build-analysis product: it has a richer application with session history, graph views, compare views, assets/chunks/modules/packages/plugins pages, and a worker for diffing.

- packages/self-inspect introspects the devtools itself, showing auth tokens, client scripts, registered plugins, docks, RPC functions, and shared-state keys.

- These packages share the same general shape: node RPC endpoints + client app pages/components + shared types.

9. Rolldown-specific architecture

- Rolldown is the most data-heavy subsystem.

- Its node side stores and reads build events/logs, manages sessions, and serves RPC endpoints for assets, chunks, modules, packages, plugins, and compare summaries.

- Its app side contains pages and specialized visualizations such as flamegraphs, treemaps, module flowmaps, graph views, search, and compare dashboards.

- A worker is used for diff computation, which keeps expensive comparison logic off the main UI thread.

10. packages/webext: browser-extension packaging

- packages/webext is the browser extension shell that wraps the devtools into extension targets.

- It contains background scripts, devtools panel/background pages, proxy/window coordination, and build scripts.

- This is the deployment layer for browser-based embedding, separate from the core rendering logic.

11. Examples as integration references

- The examples/ directory contains concrete plugin examples such as accessibility checking, file explorer, and git UI.

- Each example is split into a node plugin/backend and a playground UI for manual testing.

- These examples are important because they show how third-party tooling integrates with the kit/core contracts.

12. Testing and validation layers

- e2e/ contains end-to-end tests with a minimal Vite fixture to validate real integration behavior.

- packages/*/__tests__ and test/ cover package-level behavior and API snapshots.

- This suggests the repo treats both public API stability and runtime integration behavior as first-class concerns.

13. Documentation and release infrastructure

- docs/ is a full VitePress documentation site, including guides, kit docs, Rolldown docs, and error references.

- .github/workflows and the release scripts show automated CI/release pipelines, which matter because this repo ships multiple packages and generated artifacts.

- The repo is organized for publishable packages, not just a single app.

14. How to draw the architecture

- The clearest diagram is a layered system:

- Host integrations / plugins at the edge,

- Kit contracts in the middle,

- Node runtimes that collect state and expose RPC,

- Client apps/UI shells that render data,

- and deployment shells like the browser extension, standalone app, or example playgrounds.

- The main data path is: host/build process → node plugin/runtime → RPC/shared state → client UI components/views.