GitShow/vitejs/devtools
vitejs

devtools

DevTools Framework for the Vite Ecosystem.

by vitejs
devtools-kitrolldownvitevite-devtoolsvite-plus
Star on GitHubForkWebsitenpm

TypeScript

1.2k stars91 forks42 contributorsActive · 1d agoSince 2025v0.7.6MIT

Meet the team

See all 42 on GitHub →
antfu
antfu458 contributions
webfansplz
webfansplz332 contributions
yuyinws
yuyinws117 contributions
antfubot
antfubot87 contributions
SaKaNa-Y
SaKaNa-Y33 contributions
liangmiQwQ
liangmiQwQ20 contributions
JianJroh
JianJroh19 contributions
dvcolomban
dvcolomban11 contributions

Languages

View on GitHub →
TypeScript53.8%
Vue43.7%
JavaScript0.9%
CSS0.8%
MDX0.7%
HTML0.1%

Commit activity

Last 12 weeks · 245 commits

Full graph →

Community health

5 of 6 standards met

Community profile →
87
✓README✓License✓Contributing✓Code of Conduct○Issue Template✓PR Template

Recent PRs & issues

Active · Last activity 1d ago
See all on GitHub →
SaKaNa-Y
fix(oxc): preserve successful formatting with stderr noticesOpenPR

[!IMPORTANT] Please take a moment to read this. Thank you! I should include a brief explanation of the problem in my own words in every PR. If that explanation is missing, please @mention me and do not merge this PR until I have added it. You may also leave this PR unaddressed (because this means I have not fulfilled my responsibilities as the author). If my explanation is unclear or difficult to follow, please ask me to clarify or provide reproduction steps or supporting evidence. I welcome suggestions and counterarguments, especially questions about anything I may have overlooked. (Your feedback helps me learn and improve. 🙏) I hold myself to this standard for every PR, regardless of its size. Summary When I run Format Inspector without an Oxfmt config, Oxfmt 0.70.0 prints a defaults notice to stderr. A clean check or successful write exits with code 0, but DevTools throws and discards the result. In write mode, the file has already been formatted even though the UI reports failure. Classify the command result using its exit code and parsed status before saving it. Successful runs and check-mode formatting findings are saved even when stderr contains a notice. Execution failures still produce , using stderr or an exit-code fallback when stderr is empty. Evidence With real Oxfmt 0.70.0 and no config, the unchanged upstream handler rejects clean checks, checks with formatting findings, and successful writes. The patched handler saves all three results; write mode also produces the expected file contents. Browser verification against the rebuilt package: no-config write saves a result, and a clean check saves a result. Regression tests: 6 fail against the original handler; all 16 pass after the fix. Coverage includes notices, formatting findings, execution errors, missing exit codes, and process startup failures. , , and pass (351 tests passed, 2 skipped). reports 8 existing Vite plugin type errors in the Oxc, Rolldown, and Vite RPC modules. Re-running with both changed files restored to the upstream baseline produces identical errors. Merge Danger Door: Two-way. No persisted result schema changes. Blast Radius: Oxfmt. Changes command-result classification in Format Inspector.

SaKaNa-Y · 2d ago
hyoban
fix(rolldown): bound reader cache retention by log sizeOpenPR

Description Switching between large Rolldown traces retains up to 32 readers regardless of trace size. This can keep multiple multi-GiB sessions' parsed data alive after their requests finish. Add a 256 MiB source-log-size budget alongside the existing reader count limit, evicting the least recently used idle readers. Account for source size even when restoring disk caches, and prune again when reads settle. Readers in the current session directory and pending reads remain available, so oversized or concurrent sessions can exceed the budget; source size is a cache weight, not a heap measurement. Eviction drops cache ownership without clearing data that RPC handlers may still use. Disposing an evicted reader also checks its identity before removing the cache entry, preserving any replacement for the same path. Linked Issues None. Additional context Adds 10 regression cases covering LRU eviction, oversized sessions, count limits, retained caller data, replacement disposal, disk-cache restoration, and pending reads across all three read modes. All 10 fail on the previous implementation and pass with this change. Three additional regressions exercise , , and with separate metadata files: loading metadata preserves the oversized log reader, repeated requests reuse it, and switching sessions still evicts it. These three cases fail with reader-only protection and pass with session-level protection. Validation: , , and passed (355 passed, 2 skipped). reports the same eight existing Nuxt/Vite plugin type errors as unmodified . This is independent of #592, which bounds bulk reads during plugin detail hydration.

hyoban · 3d ago
hyoban
fix(rolldown): bound memory during plugin detail hydrationOpenPR

Description Opening plugin details on a large Rolldown trace can exhaust the heap: hydration reads every plugin's hook events before filtering, then resolves all transform contents together. Read indexed hooks in batches of up to 128 calls and 1 MiB of source event bytes, retaining only the requested plugin's metrics. Compare transform contents in groups of up to 128 calls so event payloads and resolved strings can be released between groups. An oversized hook is read alone; this bounds bulk reads rather than imposing a total heap limit. Linked Issues None. Additional context Adds five regression cases covering call and byte limits, oversized hooks, filtering and ordering across modules, transform equality, and string references with missing index entries. All five fail on the previous implementation and pass with this change. Reader cache eviction is unchanged. Validation: , , and passed (347 passed, 2 skipped). reports the same eight existing Nuxt/Vite plugin type errors as unmodified , in the Oxc, Rolldown, and Vite files.

hyoban · 3d ago

Recent fixes

View closed PRs →
morinokami
fix(core): declare client module resolution before plugin setupMergedPR

Description A plugin that registers a dock with a bare-specifier client script inside (e.g. , as the Kit docs show) gets a false warning ("the script will fail to load") on the dev server, although the script loads fine through . The hub checks inside , but core only declared it via in , which runs after has already run every plugin's . This declares the template in , before any dock registers. It stays dev-server only, so build / standalone keep warning as before. still receives the same value, which covers contexts assembled elsewhere. Linked Issues Mentioned in passing in devframes/devframe#289 ("fires even in plain Vite, where the dock works fine"), which was closed without addressing it. Additional context Reproducible with (): published 0.7.5 prints 1 warning, this branch prints 0. The advertised and the response (200) are identical in both. The added test fails without the fix.

morinokami · 4d ago
hyoban
fix: respect project paths and Vite+ build commandsMergedPR

Description Resolve Oxc config reads and editor targets from the project context so nested projects use their own files when the process starts elsewhere. Use for Rolldown analysis when Vite+ is installed, sharing the existing Vite+ detection through the kit. Linked Issues None. Additional context Adds regression coverage for nested project configs, editor paths, and build command selection, and updates the kit export snapshots. Validation: , (334 passed, 2 skipped), , and passed.

hyoban · 4d ago
zahidzorbaz
Vitest UI launcher shows Vitest 5's "requires authentication" page instead of the UIClosedIssue

Describe the bug With Vitest 5, clicking Start Vitest UI in the Vite+ group starts the server, the dock swaps to the iframe, and the iframe shows only this text instead of the Vitest UI: Vitest UI requires authentication. Open the URL with the token printed in the terminal, e.g. http://localhost:51204/__vitest__/?token=... Since Vitest 5 (vitest-dev/vitest#10583), answers unless the request carries (which sets a cookie and redirects to the clean URL) or already has that cookie. The token is printed by Vitest as and is stored in (or ). The launcher never obtains that token: The iframe URL is built as with no token (plugin.ts#L117) and returned from as-is (#L133-L137). treats any status below 500 as ready (#L192-L205), so the counts as "ready" and the auth page is embedded. Accepting 403 is fine for "is the port up", but the embedded URL then can never succeed. Possible fix: take the authenticated URL from the line of the session's stdout (via ), use it as the iframe URL, and have the readiness probe request that URL and accept only 2xx/3xx. A fallback could read the token file, but that path is a Vitest internal. Unverified, possibly related (not tested in a browser): the cookie is and the launcher hard-codes the host. If DevTools is opened on , the iframe is cross-site, so the browser may not store or send the cookie even when the token is present. Building the iframe URL on the same hostname as the DevTools page would avoid that. Related: stopping this launcher on Windows leaves the process running, see devframes/devframe#402. Reproduction Inline steps below — needs a local Vitest 5 UI (no hosted repro possible). 1. Any Vite 8 project with , , and , in the Vite config. Upstream's own should show the same, since the workspace uses . 2. Run , open DevTools, Vite+ group → Vitest → Start Vitest UI**. 3. The iframe shows the "Vitest UI requires authentication" page. The HTTP side without a browser (empty folder with one test file and an empty ; 5.0.0 + 5.0.0 installed): Output: Expected: the dock iframe shows the Vitest UI. Actual: the dock iframe shows Vitest's 403 "requires authentication" page, and the launcher reports the server as ready. System Info Used Package Manager pnpm Validations [x] Follow our Code of Conduct [x] Read the Contributing Guide. [x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate. [x] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead. [x] The provided reproduction is a minimal reproducible of the bug.

zahidzorbaz · 4d ago
Structured data for AI agents

Repository: vitejs/devtools. Description: DevTools Framework for the Vite Ecosystem. Stars: 1201, Forks: 91. Primary language: TypeScript. Languages: TypeScript (53.8%), Vue (43.7%), JavaScript (0.9%), CSS (0.8%), MDX (0.7%). License: MIT. Homepage: https://devtools.vite.dev/ Topics: devtools-kit, rolldown, vite, vite-devtools, vite-plus. Latest release: v0.7.6 (4d ago). Open PRs: 12, open issues: 23. Last activity: 1d ago. Community health: 87%. Top contributors: antfu, webfansplz, yuyinws, antfubot, SaKaNa-Y, liangmiQwQ, JianJroh, dvcolomban, arashsheyda, CoutinhoTTS and others.

·@ofershap

Replace github.com with gitshow.dev