Why dependency folders grow quickly
Modern toolchains install many small files and platform binaries. Monorepos, Electron, Playwright, and projects with native modules can be especially large. Dependencies in an abandoned project do not expire automatically.
Count bytes, not just directories named node_modules. A recent workspace can contain several packages, and its true total may be much larger than the top-level folder suggests.
Verify reproducibility before deleting
Keep package.json and the matching package-lock.json, pnpm-lock.yaml, or yarn.lock. Confirm that private registries still work. A delisted package, uncommitted patch, or local link can make the old installation impossible to reconstruct.
Commit working changes or save patches first. Do not clear dependencies from an offline demo right before travel: network access, Node versions, and native build tools all affect reinstalling.
Clean old projects selectively
Start with archived, merged, or untouched projects. In active projects, removing build output and tool caches may reclaim enough room without paying the full install cost again.
Diskly aggregates the thousands of small files into a visible directory block. Reveal each candidate in Finder and confirm project status. Avoid an unchecked recursive deletion command across your entire home directory.
Reduce duplication in the future
Standardize the team's package manager and commit lockfiles. pnpm's content-addressed store can reduce duplicate package content, although that global store should still be maintained through official commands. Archive inactive projects and record Node and package-manager versions.
After cleanup, run a strict lockfile install such as npm ci or the equivalent frozen-lockfile mode. This proves that the project can actually be restored.
Understand first, clean second
Diskly scans locally on your Mac, maps real usage in a treemap, and keeps every cleanup suggestion reviewable.
Download free trial