Deno and Bun both set out to fix parts of the JavaScript tooling experience that npm and Node made awkward, and both ended up with their own caching models that are worth understanding on their own terms rather than assuming they work like npm underneath. Neither is large by the standards of, say, a Docker or Xcode footprint, but both accumulate quietly enough on an active machine that it's worth knowing where to look.
Deno's cache: ~/.deno
Deno's whole design philosophy leans on caching remote modules rather than a package.json and node_modules install step. When your code does import { serve } from "https://deno.land/std/http/server.ts", Deno downloads that module once and caches it — by default under ~/.deno on macOS (technically inside a directory Deno computes based on your platform's standard cache location, which resolves to ~/Library/Caches/deno on modern macOS versions, or ~/.deno depending on the Deno version and configuration in play).
Check the active location directly:
deno info
which prints Deno's cache directory along with a summary of what's cached for the current context.
Inside, Deno stores downloaded remote modules, their associated TypeScript type information, and compiled output from Deno's built-in TypeScript compiler, keyed by URL and content hash so an unchanged remote module is never re-fetched or re-compiled.
deno cache --reload
deno cache --reload main.ts
This forces Deno to bypass the cache and re-fetch every remote module a given file (and its imports) depends on, overwriting what was cached before. This is the command you want when a remote module has been updated at an unpinned URL (no version or a mutable branch reference) and you need the latest content rather than what Deno cached on first run — a rarer scenario in mature Deno projects, which tend to pin exact versions in import URLs specifically to avoid this ambiguity, but common enough during early development or when following an unpinned tutorial import.
For a full wipe rather than a scoped reload:
rm -rf ~/Library/Caches/deno
(or ~/.deno, depending on your installed version) removes everything, and Deno re-downloads and recompiles as needed on the next run of any script.
Bun's cache: ~/.bun/install/cache
Bun, being closer in spirit to npm's dependency model (a package.json, an install step, a node_modules folder it produces), caches downloaded package tarballs at ~/.bun/install/cache by default. Every package version Bun has downloaded across any project on the machine lives here, content-addressed in a similar spirit to npm's _cacache or Yarn's global cache — one copy of a given package version, reused across every project's install.
Check the size:
du -sh ~/.bun/install/cache
bun pm cache rm
bun pm cache rm
Clears Bun's entire package install cache. Bun re-downloads whatever it needs on the next bun install across any project. There's no finer-grained per-package removal command built in the way pip cache remove or yarn cache clean <package> offer — it's an all-or-nothing operation for the whole cache.
You can also check where Bun considers its cache to live, in case it's been overridden in your environment:
bun pm cache
prints the cache directory path Bun is currently using.
How the two compare to npm and to each other
| npm | Deno | Bun | |
|---|---|---|---|
| Cache location on macOS | ~/.npm |
~/.deno or ~/Library/Caches/deno |
~/.bun/install/cache |
| Caches what | Downloaded tarballs | Remote modules by URL + compiled TS output | Downloaded package tarballs |
| Dependency model | package.json + node_modules |
URL imports, no node_modules by default |
package.json + node_modules (or Bun's own linking) |
| Full clear command | npm cache clean --force |
rm -rf the cache directory, or --reload per file |
bun pm cache rm |
Deno's model is the outlier here because its "dependencies" are URLs rather than named, versioned registry packages by default — although modern Deno also supports npm: specifiers and a more conventional package-based workflow when a project wants it, in which case it behaves closer to Bun's and npm's model for that portion of the dependency tree.
Why neither cache tends to be a major space problem
Compared to something like Xcode's DerivedData or a Docker VM disk, both Deno's and Bun's caches tend to stay modest — typically hundreds of megabytes rather than tens of gigabytes — because JavaScript and TypeScript source is small relative to compiled native code or container images, and both tools deduplicate by content hash aggressively. If either grows unusually large, it's usually because of a project with many large dependencies (bundled binary assets shipped inside an npm package, for instance) rather than the caching mechanism itself being wasteful.
Bun's global install mode adds a further wrinkle
Bun also supports a global package install mode conceptually similar to pnpm's content-addressable store, where packages are linked rather than copied into each project's node_modules. When this mode is in use, the actual package content lives once in a central location and is hard-linked or symlinked into individual projects, which changes the accounting: du -sh on a project's node_modules folder can under-report actual unique disk usage if many files are hard links back to Bun's central store, since hard-linked bytes are only genuinely freed once every link to them is removed, not when any single project's node_modules is deleted. This is the same accounting subtlety that applies to pnpm's store, and it's worth knowing about if the numbers from a simple project-by-project du don't add up to what your total disk usage suggests.
Both tools are still catching up on ecosystem-wide tooling support
Worth a brief practical note: because both Deno and Bun are newer than npm, some tooling that expects an npm-shaped cache (certain CI cache-restoration actions, some monitoring or disk-usage dashboards built around ~/.npm) may not recognise either cache location out of the box. If you're setting up caching in a CI pipeline that uses Deno or Bun, double-check that whatever caching mechanism your CI provider offers is actually configured to point at the correct cache directory for the runtime in use, rather than assuming it defaults correctly the way an npm-based pipeline often does.
A practical routine
deno infoanddu -sh ~/.bun/install/cacheto see current sizes for each, if you use both runtimes.deno cache --reloadscoped to a specific file if you need fresh remote module content, rather than clearing everything.bun pm cache rmfor a full Bun cache clear if you're chasing a corrupted install or just want the space back.- Neither tool needs frequent manual cleanup under normal disk pressure — they're rarely the largest developer cache on a typical Mac, so this is worth checking after the bigger, more usual suspects (Xcode, Docker, node_modules) rather than as a first step.
Where VolumeLens fits in
Even caches that stay modest individually add to the general clutter of a developer's ~/Library and home directory over time. VolumeLens scans everything in one pass and shows Deno's and Bun's cache folders sized honestly next to the rest of your tooling, so you can judge in seconds whether they're worth touching at all. See the full feature list for what else gets recognised automatically.