feat(rolldown): sessions accumulate on disk with no cleanup — need max session limit
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 64/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- build-system, tooling
Research direction
Start at DevToolsRolldownUI() and RolldownLogsManager.list(), then trace where devtools startup creates or reads .rolldown session directories. Add the maxSessions option and cleanup behavior described, using fs.rm for sessions beyond the timestamp-sorted limit; verify that maxSessions: 0 disables cleanup and missing directories are harmless.
Written by the indexing model from the issue text.
Description
Clear and concise description of the problem
When devtools is enabled in Vite (Rolldown), a new session directory is written to node_modules/.rolldown/sid_*/ on every dev server start. Each session contains logs.json (~500MB+ for medium-sized projects) and meta.json.
There is no cleanup mechanism. Sessions accumulate indefinitely.
Real-world numbers from a mid-sized React project:
node_modules/.rolldown/ → 17 GB
└── sid_* × 113 sessions → ~568 MB each
After weeks of normal development (running vite dev daily), the .rolldown directory silently consumed 17 GB of disk space — all of it stale data from previous sessions.
Root cause
RolldownLogsManager.list() reads all sessions but never deletes any. There is no retention policy, no expiry, and no option to configure one.
Suggested solution
Add a maxSessions option to DevToolsRolldownUI() with a sensible default (e.g. 10).
On devtools startup, call a new RolldownLogsManager.cleanup(maxSessions) method that:
- Reads all sessions and sorts by
timestamp(oldest first) - Deletes sessions beyond the
maxSessionslimit usingfs.rm(..., { recursive: true }) - Silently no-ops if the
.rolldowndirectory does not exist yet
Why maxSessions and not "delete all but the latest"?
PR #371 (merged 2026-06-04) introduced a Session Compare panel — users can compare two build sessions side-by-side. Keeping only 1 session would break this workflow. A configurable limit (default 10) preserves the compare experience while bounding disk growth.
Setting maxSessions: 0 opts out of automatic cleanup entirely.
Validations
- Follow our Code of Conduct
- Read the Contributing Guide.
- Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
- Dominant language
- TypeScript
- Stars
- 1.2k
- Forks
- 89
- Avg merge
- 18h 46m
- Merged PRs (30d)
- 24
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from vitejs/devtools
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
enhancement
-
pending triage
Difficulty 3/5 1-2 days Newbie friendliness 58/100
-
pending triage
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
pending triage
Difficulty 3/5 1-2 days Newbie friendliness 62/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
fullcalendar/fullcalendar#8106 ·