JavaScript build caches: .next, Turborepo, Vite and friends on Mac

How big should a Next.js .next folder be? On one developer's Mac measured for this post, the Next cache folder size ranged from almost nothing to 1.2 GB per project, with half of the 29 folders under 190 MB. In six of the seven largest, most of the space was cache: Turbopack's development cache first, then the build cache.

All of it is safe to remove. Next.js makes .next again the next time you start the development server or build, and the only cost is a slower first start. The same goes for Turborepo's .turbo/cache, Vite's cache in node_modules/.vite, Parcel's .parcel-cache, Angular's .angular/cache, and the .nuxt and .svelte-kit folders.

The catch is where they are. Their names start with a dot, so Finder hides them. There's one in every project that uses the tool, and in every copy of that project, and only some of them ever trim themselves.

This post goes tool by tool: what each cache holds, how it grows, what removing it costs and how to keep it in check. Installed packages and package managers' caches have their own posts, on deleting node_modules folders and on npm, Yarn, pnpm and Bun caches.

Next cache folder size: what's inside .next

Next.js writes everything it generates to one folder in each project, .next, unless the project's configuration names another with the distDir setting. Inside are several things with very different jobs, and it helps to know which is which before removing any of them.

What's in a .next folder?

Inside .next	What it holds	Made by
dev	Everything the development server writes, since Next.js 16	Starting the development server
dev/cache/turbopack	Turbopack's saved work, so a restarted server starts warm	The development server
cache/turbopack	Turbopack's saved work for production builds	A production build
cache/images	Optimized copies of images the app has served	The image optimizer
server and static	The production build of your app	A production build
standalone	A copy of the app that runs without node_modules	A build with standalone output turned on

Projects that build with webpack rather than Turbopack keep a webpack folder in the same places instead. On the Mac measured for this post, one such project had about 350 MB of webpack cache in .next/dev/cache.

Why did .next get bigger with Next.js 16?

Three changes added up. Next.js 16 gave the development server its own output folder, .next/dev, so it and a production build can run at the same time. Before that, both wrote to .next itself.

Next.js 16.1 then turned on Turbopack's file system cache for the development server by default, and 16.3 did the same for production builds. Each keeps Turbopack's work between runs so the next start or build is faster.

Turbopack can also remove work it no longer needs from that cache, but only with an experimental option added in Next.js 16.4, and it's off by default. Without it, the cache keeps what it has saved until you remove it.

How big does .next get?

On the Mac measured for this post, the 29 .next folders held 9.9 GB together. The largest single folder was 1.2 GB, and 725 MB of that was Turbopack's development cache. The production build itself, the part that runs your app, was usually the smaller share.

• All 29 .next folders9.9 GB · Safe
• The 21 inside Git worktrees5.3 GB · Safe
• Development caches inside them3.9 GB · Safe
• Build caches inside them1.4 GB · Safe

Sizes on disk of every .next folder in one developer's projects folder in October 2026. The last three bars are parts of the first, not additions to it. Your projects will differ.

Twenty-one of those 29 folders were in Git worktrees: extra copies of a project, each with its own .next. More on those below, because they're often the easiest space to get back.

What about monorepos with several Next.js apps?

Each app has its own .next, in its own folder, such as apps/web and apps/docs. A monorepo with a website, a documentation site and an admin app keeps three, and each grows with its own caches.

They're independent: removing one app's .next doesn't touch the others. If you only work on one app in a repository, the others' folders are the ones to clear.

Can the image cache fill the disk?

It could, in older versions. Next.js's security advisory says its image optimization cache had no configurable upper limit from version 10, and that versions 15.5.14 and 16.1.7 fixed it. On older versions, the advisory's suggestion is to clear .next/cache/images from time to time.

Since 16.1.7, the image cache has a size limit set by maximumDiskCacheSize in the project's Next.js configuration. If it isn't set, Next.js checks the free space once at startup and allows half of it. Past the limit, it deletes the least recently used images.

That default is generous on a laptop with plenty of free space. If a project optimizes many images, a fixed number in the configuration keeps the folder predictable, and zero turns the disk cache off.

Is it safe to delete the .next folder?

Yes. Nothing in .next is something you wrote, and Next.js creates all of it again. The catalog entry for the .next folder (Next.js) rates it safe for exactly that reason.

What do you lose when you delete .next?

Time, and nothing else. The next start of the development server compiles from scratch, and so does the next build. Until you build again, the project can't run in production mode, because the production build was in .next too.

Your code, package.json, the lock file, environment files and Git history are all outside .next. So are your installed packages, which means you don't need to install anything again.

Should you remove only .next/cache?

You can. .next/cache holds the production build's cache, and .next/dev/cache holds the development server's. On the measured Mac, the development caches were the larger: 3.9 GB against 1.4 GB.

For a project you're not working on, the whole folder is simpler. Partial cleanups make sense for the project you're in the middle of, where you'd rather keep the production build and lose only the cache.

When should you keep it?

• You're working on the project today. Removing the cache only means waiting for it to come back.
• You deploy from a build made on your Mac, for example from the standalone folder. Remove it after the deploy, not before.
• The project uses a Next.js version you can't install again, or packages you no longer have access to. Then a build is the only copy that runs.

Does clearing .next make Next.js faster?

No. The first start and the first build afterwards are slower, because the cache was there to save that work. Clearing it frees space on your Mac and nothing else.

Developers sometimes clear .next when a build behaves strangely, as a reset. That's a separate reason from space, and either way the cache fills again as you work.

Turborepo: the .turbo cache in monorepos

Turborepo runs tasks such as builds, tests and linting across the packages of a repository. When a task's inputs haven't changed, it restores the saved result instead of running the task again. Those saved results are its local cache.

What does Turborepo keep in .turbo?

By default, the cache is .turbo/cache at the root of the repository. It holds the files each task produced, as declared in the repository's turbo.json, along with the task's terminal output, which Turborepo always captures.

Each package in the repository can have a small .turbo folder of its own. On the Mac measured for this post, those held only text logs of a few bytes each; the cache itself was at the root, as compressed archives named by a code.

How big does the Turborepo cache get?

It depends on what the tasks save. Lint and type-check tasks save little more than their logs, while a build that saves a whole app's output saves all of it, once for every change that produces a new result.

On the measured Mac, the two monorepos' caches were small: 28 MB and under 1 MB. Both left Next.js's own cache out of what their builds saved, which is the setting that makes the difference, as the next answer explains.

Does Turborepo clean its cache by itself?

Not by default. Turborepo has two settings for turbo.json, cacheMaxAge and cacheMaxSize, and both are off unless you set them. With them on, it removes old entries at the start of each run, then the oldest ones until the cache is under the size you chose.

Turborepo's documentation says this local cleanup is opt-in for now and expected to become the default in version 3.0. Until then, unless you set them, the cache grows as your code changes.

Why can a Next.js app make the Turborepo cache huge?

Because a build task's saved files can include Next.js's own cache. If turbo.json saves everything in .next as the build's output, every build stores a copy of .next/cache in Turborepo's cache too.

Vercel's own check for this says it can make the cache grow to an excessive size. The fix it gives is to exclude .next/cache from the build task's outputs, so Turborepo saves the production build and leaves Next.js's cache to Next.js.

Since Next.js 16, .next/dev holds the development server's files and its cache, so it's worth leaving out the same way. One of the two repositories on the measured Mac did exactly that.

Do Git worktrees get their own cache?

Not in current versions. If turbo.json doesn't set a cache folder, Turborepo sends the cache of a linked Git worktree to the main worktree's .turbo/cache, so every copy shares one.

Setting a cache folder explicitly turns that sharing off, even if you set it to the default path. Then each worktree keeps a cache of its own.

Is it safe to delete .turbo/cache?

Yes. The catalog's Turborepo local cache entry rates it safe: the next run of each task does the full work again instead of restoring a result. If your team uses a remote cache, Turborepo downloads results from it when the local copy is missing, so the cost is a download rather than a rebuild.

Vite, Vitest and webpack: caches inside node_modules

Some tools keep their cache inside the project's node_modules folder rather than next to it. That has one convenience: removing node_modules takes the cache with it.

What is node_modules/.vite?

Vite's cache. When the development server starts, Vite pre-bundles your dependencies and keeps the result in node_modules/.vite. It runs that step again only when the lock file, the patches folder, parts of Vite's configuration or the environment mode change.

Vite's documentation says that deleting the folder by hand is one way to make it pre-bundle again. Nothing else is lost: the next start of the development server takes longer while it rebuilds. On the Mac measured for this post, the largest was 5 MB.

What does Vitest keep there?

Vitest, the test runner built on Vite, keeps a small record of each test file in the same cache folder: whether it failed, how long it took and when it last ran. It uses the record to run failed and slow tests first.

It's tiny, and Vitest has its own option to clear it. Removing it costs nothing but the order of the next run.

What about webpack's cache?

webpack can keep a cache on disk between builds, and its default place is node_modules/.cache/webpack. In webpack's own defaults, development builds cache in memory and production builds don't cache, so the disk cache appears when a project or framework turns it on.

When it does, webpack removes entries that have gone unused for a set time, which its documentation gives as a month by default. On the Mac measured for this post, a video project built with webpack held 160 MB there.

Why does node_modules/.cache fill up?

It's a shared place many tools use. On the measured Mac, most projects had nearly empty folders there from tools such as Cloudflare's Wrangler, and Nuxt's own cleanup command lists node_modules/.cache among the generated files it removes.

Everything in it comes back when a tool needs it. Since it lives inside node_modules, removing a finished project's node_modules clears it too, which the node_modules post covers.

Parcel, Angular, Nuxt, SvelteKit, Nx and friends

Most frameworks and build tools keep a folder of generated files in each project. The names differ, but the idea is the same: work saved so the next run is faster, or files generated so your app can run.

Where does each tool keep its cache?

Tool	Where	What it holds	Limits itself?
Parcel	.parcel-cache	Everything it built, reused in later builds	Not described
Angular CLI	.angular/cache	Results of build steps, reused by builds and tests	Not described
Nuxt	.nuxt	Code and types generated for the development server	Rebuilt on each start
SvelteKit	.svelte-kit	Generated code, types and build output	Not described
Astro	node_modules/.astro	Build artifacts reused in later builds	Not described
Nx	A folder per workspace in ~/.nx	Results of tasks	Yes, by age and size
ESLint	.eslintcache	Which files it has already checked	Not described

"Not described" means the tool's documentation doesn't mention a size limit or cleanup. Each of these comes back by itself the next time the tool runs.

Which tools clean up after themselves?

Nx does the most. It removes cached results that haven't been used in seven days, and by default it keeps the cache under 10% of the disk it's on, up to 10 GB, removing the least recently used results first.

Older Nx versions kept the cache in each workspace, in .nx/cache. Current versions keep it outside, in a hidden .nx folder in your home folder, shared by every copy of the workspace.

Nuxt rebuilds .nuxt from scratch every time the development server starts, so it doesn't pile up. webpack trims unused entries, and Next.js trims its image cache. The others keep what they've saved until it's removed.

What does Nuxt consider safe to remove?

Nuxt has a cleanup command, and its documentation lists what it removes: the .nuxt folder, the .output folder, dist, node_modules/.vite and node_modules/.cache. That list is a useful guide to what a framework itself regards as generated and disposable.

In Finder, the equivalent is moving those folders to the Trash, as described below. The catalog's .nuxt folder (Nuxt) entry covers .nuxt itself.

What about Angular's cache command?

The Angular command-line tool has a cache command with two parts: one prints the cache's settings and statistics, and one deletes the cache from disk. Angular has no app or window for it.

By default, Angular only keeps the disk cache on development machines, not on build servers. Moving .angular/cache to the Trash in Finder does the same as its delete command; the next build is slower while it fills again.

Where do Jest and other test tools keep theirs?

Outside the project. Jest stores what it learns about your dependency tree in a temporary folder, which its documentation gives as one in /tmp by default. Removing a project doesn't remove it. Jest's command-line tool has an option to delete it, and Jest's documentation warns that the next runs are slower.

Build output folders: dist, build, out and .output

A build's output isn't a cache. It's the finished app: the files you deploy or publish. Most of it can be made again, but unlike a cache, you might need the exact copy you have.

Which folders are build output?

• Vite and Astro write their builds to dist by default, and Vite empties it before each build when it's inside the project.
• Next.js writes a static export to out, and a standalone build to .next/standalone.
• Nuxt writes its production build to .output, and makes the whole folder again on every build.
• Many other tools use build or dist, or a name set in the project's configuration.

When is it safe to remove build output?

When the project still builds, and you don't need that particular copy. For a website a hosting service builds from your repository, the service makes its own copy, so the one on your Mac is spare.

Look twice when a project publishes a package or desktop app from your Mac, or when you've kept an old build on purpose. And a folder named build isn't always output: in some projects it holds scripts or settings someone wrote.

How can you tell output from files you need?

Open the project in your code editor and look at its .gitignore file. Folders listed there aren't stored in Git, and generated folders such as .next, dist and .turbo are usually among them. A folder that isn't listed, and has files in Git, is part of the project.

The scripts section of package.json helps too: its build script names the tool that writes the output, and that tool's documentation says where.

Finding build caches across your projects in Finder

Finder can show and clear all of these without Terminal, but it takes a few steps, because each folder is hidden and you go project by project.

Why don't they show up in Finder?

Folders whose names start with a dot are hidden in Finder, and Finder's search leaves them out. So a projects folder can look small in Finder while its build caches add up to gigabytes.

The project folder's own size still counts them. Select a project, choose File › Get Info, and compare its size with the folders you can see inside. A big difference usually means hidden folders: build caches, or Git's own data.

How do you open and measure one?

1. In Finder, choose Go › Go to Folder.
2. Type the path to the folder, such as ~/Projects/my-site/.next, and press Return. The tilde stands for your home folder.
3. Choose View › as List, then View › Show View Options, and select Calculate all sizes.

The Size column then shows each part, such as cache, dev and server. Click the column's heading to put the largest first. The steps are the same in macOS 27 Golden Gate and macOS 26 Tahoe.

Can you see all of them at once?

Not in Finder. Its search skips hidden folders, so there's no single list of every .next or .turbo in your projects. The practical route is to compare projects by size: in your projects folder, choose View › as List, turn on Calculate all sizes, and click the Size column's heading.

The largest projects are where to look first. Open each with Go › Go to Folder and check its build folders, as above. A storage tool that reads hidden folders can list them all in one place.

How do you clear one without Terminal?

1. Stop the project's development server, build or test run, if one is running.
2. Open the folder with Go › Go to Folder, as above.
3. Choose Edit › Select All, then File › Move to Trash.

The folder itself stays, now empty, and the tool fills it again on its next run. Everything you moved is in the Trash, where File › Put Back returns it, until you empty the Trash.

Where do Git worktrees hide extra copies?

A Git worktree is a second working copy of a repository, often made by an editor or an AI coding tool so it can work on a branch without touching yours. Each one is a full project folder with its own .next, node_modules and other build folders.

On the Mac measured for this post, 21 of 29 .next folders were in worktrees, many in hidden folders inside the projects. When you've merged or dropped a worktree's branch, remove the worktree with the tool that made it, and its build folders go with it.

A worked example: one developer's projects folder

The Mac measured for this post is one developer's, not an average, but it shows the pattern well. Its projects folder held 29 .next folders, 9.9 GB together, alongside a few small Turborepo, Vite and webpack caches.

Where was the space?

Eight of the .next folders were in the projects themselves, 4.6 GB together. The three largest held 3.3 GB between them, and one of the eight was in a second clone of another project, named after the fix it was made for.

The other 21, 5.3 GB together, were in Git worktrees inside the projects, made by an AI coding tool. Any worktree whose site had been run or built had a full .next of its own.

What should you clear first?

1. Worktrees whose branches are merged or dropped. Removing one takes its .next, its node_modules and everything else, and a merged branch's code is in the repository's history.
2. Extra clones made for a one-off fix, once the fix is merged.
3. The .next folders of projects you haven't opened in a month or more.
4. Last, the caches inside .next for projects you're working on now, and only if you need the space today.

What does that give back?

The first step accounts for up to 5.3 GB of .next folders here, before counting the worktrees' installed packages. The third depends on how many projects are paused; on this Mac, the three largest .next folders alone held 3.3 GB.

None of it needs Terminal, and all of it goes to the Trash first. The only thing it costs is a slower first start for each project you open again.

What clearing build caches costs, and what it doesn't fix

Every folder in this post comes back by itself. The table shows what each costs on the next run, which is the only real cost of removing it.

What does each one cost to remove?

Folder	What the next run does	Keep it when
.next	Compiles from scratch, then builds again before production use	You deploy from it, or work on the project today
.next/cache and .next/dev/cache	Starts cold, then saves again	You're in the middle of the project
.turbo/cache	Runs each task in full, or downloads from a remote cache	A long monorepo build you'll run again today
node_modules/.vite	Pre-bundles dependencies again	Rarely matters: it's small
.parcel-cache, .angular/cache	Rebuilds everything once	You're in the middle of the project
dist, build, out, .output	Nothing until you build again	You need that exact build

Does clearing build caches speed up your Mac?

No. It frees space and nothing else. Your Mac doesn't run faster because a project's caches are gone, and your builds run slower the first time afterwards.

Space matters when the disk is nearly full, for example when a macOS update needs room. Then a few gigabytes of caches from finished projects are some of the cheapest space to give back.

Mistakes to avoid

• Clearing a folder while its development server is running. The server can stop working or write a half-finished cache.
• Removing .next/standalone or dist before you've deployed it, if you deploy from your Mac.
• Removing a whole project to free space. Its code may not be anywhere else; build folders alone are usually enough.
• Removing a folder called build on the strength of its name. Check .gitignore first.
• Pasting cleanup commands from a web page. Commands that delete folders skip the Trash, and one run in the wrong folder removes what you didn't mean to.

How do you keep build caches from growing back?

• Remove finished worktrees with the tool that made them, so their build folders go too.
• In Turborepo repositories, set cacheMaxAge or cacheMaxSize in turbo.json, and keep .next/cache out of the build's saved outputs.
• In Next.js projects that serve many images, set maximumDiskCacheSize for the image cache.
• Every month or two, clear the build folders of projects you haven't opened since last time.

Can you move build caches to another drive?

Some tools let you choose where the cache goes: Turborepo, Vite, Parcel, Angular and Nx each have a setting or option for it. Next.js is the exception. Its documentation says the folder set by distDir must stay inside the project.

Moving a cache to an external drive rarely pays off. Builds read and write caches constantly, and clearing old ones frees the same space with less to manage.

Should build caches be in Time Machine backups?

They don't need to be: everything in them comes back without a backup. To leave a folder out in macOS 27 or macOS 26, choose Apple menu › System Settings, click General, then Time Machine. Click Options, click the Add button, choose the folders, then click Done.

Apple notes that excluded items still appear in Time Machine's local snapshots. Hidden folders don't appear in the dialog Time Machine opens, so excluding them one by one is fiddly; excluding a folder of finished projects is simpler, if their code is safe on a Git host.

How the app does it

Wombit finds the .next, .nuxt, .svelte-kit and .parcel-cache folders that sit next to a package.json, and Turborepo's and Angular's caches, anywhere in your home folder outside Library. Select one on the map to see what it is and what removing it costs.

All of them are Safe: the tool makes them again and nothing you wrote is lost. They count toward the safe-to-remove total and start checked in Cleanup, except inside Documents and Desktop, where nothing is checked for you. What you remove goes to the Trash, where Put Back returns it.

A project's node_modules, with Vite's and webpack's caches inside it, is Usually safe, because it comes back only when you install again. Hard links and APFS clones count once, and file names and paths never leave your Mac.

• ~/**/.next

  .next folder (Next.js)

  Build output and caches Next.js creates in a project when it runs or builds the app.

  Safe · Moves it to the Trash

• ~/**/.turbo/cache

  Turborepo local cache

  Saved task results that Turborepo restores instead of running builds and tests again.

  Safe · Moves it to the Trash

• ~/**/.parcel-cache

  .parcel-cache folder (Parcel)

  Build results Parcel saves in a project so it only rebuilds what changed.

  Safe · Moves it to the Trash

• ~/**/.angular/cache

  Angular CLI cache

  Build results the Angular CLI saves in a project so later builds and tests run faster.

  Safe · Moves it to the Trash

• ~/**/.nuxt

  .nuxt folder (Nuxt)

  Files Nuxt generates in a project while it develops and builds the app.

  Safe · Moves it to the Trash

• ~/**/.svelte-kit

  .svelte-kit folder (SvelteKit)

  Files SvelteKit generates in a project while it develops and builds the app.

  Safe · Moves it to the Trash

• ~/**/node_modules

  node_modules

  A JavaScript project's installed dependencies, which its package manager can install again.

  Usually safe · Moves it to the Trash

Seeing all of this is free. Cleanup is PRO, one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.