[{"data":1,"prerenderedAt":56},["ShallowReactive",2],{"blog-en-clear-js-package-caches":3},{"meta":4,"html":14,"headings":15,"raw":55},{"title":5,"description":6,"topic":7,"date":8,"author":9,"icons":10},"How to Clear npm, pnpm, and Yarn Caches Without Breaking Your Projects","Tell global package caches apart from node_modules, clear npm, pnpm, and Yarn caches with their official commands, and avoid a few common traps.","developer-cleanup","2026-10-29","WashBear Team",[11,12,13],"package","terminal","package-minus","\u003Cp>The more dependencies you install, the bigger the caches your package managers collect in your home folder; several gigabytes, sometimes tens of gigabytes, is common. These caches are designed to be deletable, and the worst case is usually re-downloading packages on the next install. In a few situations, though, they are more than a cache. Below are the locations, commands, and caveats for npm, pnpm, and Yarn.\u003C\u002Fp>\n\u003Ch2 id=\"cache-vs-node-modules\">\u003Ca class=\"heading-anchor\" href=\"#cache-vs-node-modules\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>A cache is not node_modules\u003C\u002Fh2>\n\u003Cp>A global cache is a local copy of packages the package manager has downloaded. All projects share it, and deleting it does not change any project files. \u003Ccode>node_modules\u003C\u002Fcode> holds the dependencies actually installed in each project; delete it and the project must be installed again before it runs. This article covers the former. To clean up \u003Ccode>node_modules\u003C\u002Fcode> in old projects in bulk, see \u003Ca href=\"\u002Fen\u002Fblog\u002Fclean-project-build-artifacts\">cleaning build folders in old projects\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2 id=\"cache-locations\">\u003Ca class=\"heading-anchor\" href=\"#cache-locations\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>Where the caches live\u003C\u002Fh2>\n\u003Cdiv class=\"table-wrap\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Tool\u003C\u002Fth>\u003Cth>Default location on macOS\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>npm\u003C\u002Ftd>\u003Ctd>\u003Ccode>~\u002F.npm\u002F_cacache\u003C\u002Fcode>; tools installed temporarily by npx live in \u003Ccode>~\u002F.npm\u002F_npx\u003C\u002Fcode>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>pnpm\u003C\u002Ftd>\u003Ctd>Store in \u003Ccode>~\u002FLibrary\u002Fpnpm\u002Fstore\u003C\u002Fcode>, metadata cache in \u003Ccode>~\u002FLibrary\u002FCaches\u002Fpnpm\u003C\u002Fcode>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Yarn 1\u003C\u002Ftd>\u003Ctd>\u003Ccode>~\u002FLibrary\u002FCaches\u002FYarn\u003C\u002Fcode>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Yarn 2 and later\u003C\u002Ftd>\u003Ctd>Global cache, enabled by default, in \u003Ccode>~\u002F.yarn\u002Fberry\u002Fcache\u003C\u002Fcode>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Bun\u003C\u002Ftd>\u003Ctd>\u003Ccode>~\u002F.bun\u002Finstall\u002Fcache\u003C\u002Fcode>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Corepack\u003C\u002Ftd>\u003Ctd>\u003Ccode>~\u002F.cache\u002Fnode\u002Fcorepack\u003C\u002Fcode>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>If you changed any of these in your configuration, trust the location each tool reports; the commands below show you how to check.\u003C\u002Fp>\n\u003Ch2 id=\"before-you-clean\">\u003Ca class=\"heading-anchor\" href=\"#before-you-clean\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>What to know before you clean\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Packages are downloaded again\u003C\u002Fstrong>: after you clear a cache, the next install fetches everything from the network again. Think twice if you work offline, have a slow connection, or depend on a private registry.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>pnpm space is shared\u003C\u002Fstrong>: on APFS disks, pnpm places store files into projects as copy-on-write clones by default, so a project's \u003Ccode>node_modules\u003C\u002Fcode> and the store share the same data blocks. Deleting only one side may free less space than the size shown.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Global installs may depend on the store\u003C\u002Fstrong>: according to the pnpm documentation, recent versions run packages installed with \u003Ccode>pnpm add -g\u003C\u002Fcode> through a \u003Ccode>links\u003C\u002Fcode> folder inside the store by default, so deleting the whole store means reinstalling those global tools. The same applies to Bun's \u003Ccode>globalStore\u003C\u002Fcode> (off by default) when enabled: affected projects need \u003Ccode>bun install\u003C\u002Fcode> again.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Yarn PnP projects read straight from the cache\u003C\u002Fstrong>: Yarn projects using Plug'n'Play have no \u003Ccode>node_modules\u003C\u002Fcode>; their dependencies are the zip files in the cache. After clearing the cache, run \u003Ccode>yarn install\u003C\u002Fcode> before starting such a project.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"manual-cleanup\">\u003Ca class=\"heading-anchor\" href=\"#manual-cleanup\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>Manual cleanup commands\u003C\u002Fh2>\n\u003Ch3 id=\"npm\">\u003Ca class=\"heading-anchor\" href=\"#npm\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>npm\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\"># Show the cache root; the default is ~\u002F.npm\nnpm config get cache\ndu -sh ~\u002F.npm\u002F_cacache ~\u002F.npm\u002F_npx\n# Verify the cache and garbage-collect unneeded data without clearing it\nnpm cache verify\n# Clear the _cacache download cache; node_modules in your projects is untouched\nnpm cache clean --force\n# Remove tools installed temporarily by npx; they are downloaded again on the next run\nrm -rf ~\u002F.npm\u002F_npx\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>npm's cache is self-healing, and the \u003Ca href=\"https:\u002F\u002Fdocs.npmjs.com\u002Fcli\u002Fv11\u002Fcommands\u002Fnpm-cache\" target=\"_blank\" rel=\"noopener\">npm documentation\u003C\u002Fa> says there is no reason to clear it other than reclaiming disk space. If an install fails, try \u003Ccode>npm cache verify\u003C\u002Fcode> first.\u003C\u002Fp>\n\u003Ch3 id=\"pnpm\">\u003Ca class=\"heading-anchor\" href=\"#pnpm\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>pnpm\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\"># Show the current store location, for example ~\u002FLibrary\u002Fpnpm\u002Fstore\u002Fv10\npnpm store path\ndu -sh "$(pnpm store path)"\n# Remove only packages that no project references\npnpm store prune\n# The metadata cache can be deleted outright; pnpm downloads it again as needed\nrm -rf ~\u002FLibrary\u002FCaches\u002Fpnpm\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>The \u003Ca href=\"https:\u002F\u002Fpnpm.io\u002Fcli\u002Fstore\" target=\"_blank\" rel=\"noopener\">pnpm documentation\u003C\u002Fa> notes that \u003Ccode>pnpm store prune\u003C\u002Fcode> has no side effects on your projects and recommends running it occasionally, not too often, because packages you just removed may be needed again soon. pnpm uses one store per disk: for projects on an external disk, the store is usually \u003Ccode>.pnpm-store\u003C\u002Fcode> at the root of that disk, and running \u003Ccode>pnpm store path\u003C\u002Fcode> inside such a project shows it.\u003C\u002Fp>\n\u003Ch3 id=\"yarn\">\u003Ca class=\"heading-anchor\" href=\"#yarn\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>Yarn\u003C\u002Fh3>\n\u003Cp>Yarn 1 and Yarn 2+ use different commands, so first run \u003Ccode>yarn --version\u003C\u002Fcode> to see which version is active in the current directory.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\"># Yarn 1: show and clear the global cache\nyarn cache dir\nyarn cache clean\n# Yarn 2 and later: run inside a project that uses it; clears only the global cache\nyarn cache clean --mirror\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Ccode>yarn cache clean --all\u003C\u002Fcode> also deletes the current project's local cache. If a project commits \u003Ccode>.yarn\u002Fcache\u003C\u002Fcode> to its repository (Zero-Installs), do not use \u003Ccode>--all\u003C\u002Fcode> in that project.\u003C\u002Fp>\n\u003Ch3 id=\"bun-corepack\">\u003Ca class=\"heading-anchor\" href=\"#bun-corepack\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>Bun and Corepack\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\"># Show Bun's global cache location\nbun pm cache\n# Clear Bun's global cache\nbun pm cache rm\n# Remove package manager versions downloaded by Corepack; they are fetched again when used\nrm -rf ~\u002F.cache\u002Fnode\u002Fcorepack\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"washbear\">\u003Ca class=\"heading-anchor\" href=\"#washbear\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>Clean up with WashBear\u003C\u002Fh2>\n\u003Cp>A \u003Cstrong>Standard Scan\u003C\u002Fstrong> in \u003Ca href=\"\u002Fen\u002Fdocs\u002Fdeep-clean\">Deep Cleanup\u003C\u002Fa> checks the default locations of these caches and lists them in two categories, depending on where they live:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Developer tools\u003C\u002Fstrong>: \u003Cstrong>npm download cache\u003C\u002Fstrong>, \u003Cstrong>npx temporary tools\u003C\u002Fstrong>, and \u003Cstrong>Bun package cache\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>User cache files\u003C\u002Fstrong>: \u003Cstrong>pnpm store cache\u003C\u002Fstrong> (the store plus the metadata cache), \u003Cstrong>Yarn download cache\u003C\u002Fstrong> (the global caches of Yarn 1 and Yarn 2+), \u003Cstrong>node-gyp build cache\u003C\u002Fstrong>, and \u003Cstrong>Node.js tooling cache\u003C\u002Fstrong> for downloads by Corepack, Electron, and similar tools. These items include folders under \u003Ccode>~\u002FLibrary\u002FCaches\u003C\u002Fcode>, which is why they appear here.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Smart recommendation\u003C\u002Fstrong> preselects the npm, npx, and node-gyp items; select the pnpm store, Yarn, Bun, and the Node.js tooling cache yourself if you want them. WashBear deletes the entire cache or store folder, which amounts to a full clear, not a \u003Ccode>pnpm store prune\u003C\u002Fcode> that removes only unreferenced packages. If you rely on pnpm global installs or have Yarn projects using PnP, read the caveats above before selecting these items.\u003C\u002Fp>\n\u003Cdiv class=\"callout callout-note\">\u003Cp class=\"callout-title\">Note\u003C\u002Fp>\u003Cp>WashBear only checks default locations, so caches you moved elsewhere and pnpm stores on other disks are not found. \u003Ccode>node_modules\u003C\u002Fcode> folders inside projects belong to the \u003Cstrong>Project build artifacts\u003C\u002Fstrong> category and are never preselected. Cleanup deletes files directly instead of moving them to the Trash, and the result is recorded in \u003Ca href=\"\u002Fen\u002Fdocs\u002Fgetting-started#history\">Operation History\u003C\u002Fa>.\u003C\u002Fp>\n\u003C\u002Fdiv>\u003Cp>To see how large these caches are on your Mac, \u003Ca href=\"\u002Fen\u002Fdownload\">download WashBear\u003C\u002Fa> and run a scan; scanning alone never deletes anything. The demo below uses sample data, so its items, categories, and selections are only illustrative.\u003C\u002Fp>\n\u003C!--demo:deepClean-->\u003Ch2 id=\"faq\">\u003Ca class=\"heading-anchor\" href=\"#faq\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>FAQ\u003C\u002Fh2>\n\u003Ch3 id=\"faq-projects-still-run\">\u003Ca class=\"heading-anchor\" href=\"#faq-projects-still-run\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>Will my projects still work after I clear the caches?\u003C\u002Fh3>\n\u003Cp>Yes. Dependencies are already installed in each project's \u003Ccode>node_modules\u003C\u002Fcode>, and deleting a global cache does not change them; the next install just spends more time downloading. The exceptions are the Yarn PnP projects and pnpm global tools that run from the store, as described above.\u003C\u002Fp>\n\u003Ch3 id=\"faq-how-often\">\u003Ca class=\"heading-anchor\" href=\"#faq-how-often\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>How often should I clear them?\u003C\u002Fh3>\n\u003Cp>There is no need to clear them on a schedule. Clear them when your disk is tight, or run \u003Ccode>pnpm store prune\u003C\u002Fcode> and \u003Ccode>npm cache verify\u003C\u002Fcode> every few months.\u003C\u002Fp>\n\u003Ch3 id=\"faq-space-not-freed\">\u003Ca class=\"heading-anchor\" href=\"#faq-space-not-freed\" aria-hidden=\"true\" tabindex=\"-1\">#\u003C\u002Fa>Why did deleting the pnpm store free less space than expected?\u003C\u002Fh3>\n\u003Cp>Because \u003Ccode>node_modules\u003C\u002Fcode> folders you still use reference the same data blocks. Remove \u003Ccode>node_modules\u003C\u002Fcode> from old projects you no longer use, and that space is actually released.\u003C\u002Fp>\n",[16,20,23,26,29,32,34,37,40,43,46,49,52],{"depth":17,"id":18,"text":19},2,"cache-vs-node-modules","A cache is not node_modules",{"depth":17,"id":21,"text":22},"cache-locations","Where the caches live",{"depth":17,"id":24,"text":25},"before-you-clean","What to know before you clean",{"depth":17,"id":27,"text":28},"manual-cleanup","Manual cleanup commands",{"depth":30,"id":31,"text":31},3,"npm",{"depth":30,"id":33,"text":33},"pnpm",{"depth":30,"id":35,"text":36},"yarn","Yarn",{"depth":30,"id":38,"text":39},"bun-corepack","Bun and Corepack",{"depth":17,"id":41,"text":42},"washbear","Clean up with WashBear",{"depth":17,"id":44,"text":45},"faq","FAQ",{"depth":30,"id":47,"text":48},"faq-projects-still-run","Will my projects still work after I clear the caches?",{"depth":30,"id":50,"text":51},"faq-how-often","How often should I clear them?",{"depth":30,"id":53,"text":54},"faq-space-not-freed","Why did deleting the pnpm store free less space than expected?","\nThe more dependencies you install, the bigger the caches your package managers collect in your home folder; several gigabytes, sometimes tens of gigabytes, is common. These caches are designed to be deletable, and the worst case is usually re-downloading packages on the next install. In a few situations, though, they are more than a cache. Below are the locations, commands, and caveats for npm, pnpm, and Yarn.\n\n## A cache is not node_modules {#cache-vs-node-modules}\n\nA global cache is a local copy of packages the package manager has downloaded. All projects share it, and deleting it does not change any project files. `node_modules` holds the dependencies actually installed in each project; delete it and the project must be installed again before it runs. This article covers the former. To clean up `node_modules` in old projects in bulk, see [cleaning build folders in old projects](\u002Fblog\u002Fclean-project-build-artifacts).\n\n## Where the caches live {#cache-locations}\n\n| Tool | Default location on macOS |\n| --- | --- |\n| npm | `~\u002F.npm\u002F_cacache`; tools installed temporarily by npx live in `~\u002F.npm\u002F_npx` |\n| pnpm | Store in `~\u002FLibrary\u002Fpnpm\u002Fstore`, metadata cache in `~\u002FLibrary\u002FCaches\u002Fpnpm` |\n| Yarn 1 | `~\u002FLibrary\u002FCaches\u002FYarn` |\n| Yarn 2 and later | Global cache, enabled by default, in `~\u002F.yarn\u002Fberry\u002Fcache` |\n| Bun | `~\u002F.bun\u002Finstall\u002Fcache` |\n| Corepack | `~\u002F.cache\u002Fnode\u002Fcorepack` |\n\nIf you changed any of these in your configuration, trust the location each tool reports; the commands below show you how to check.\n\n## What to know before you clean {#before-you-clean}\n\n- **Packages are downloaded again**: after you clear a cache, the next install fetches everything from the network again. Think twice if you work offline, have a slow connection, or depend on a private registry.\n- **pnpm space is shared**: on APFS disks, pnpm places store files into projects as copy-on-write clones by default, so a project's `node_modules` and the store share the same data blocks. Deleting only one side may free less space than the size shown.\n- **Global installs may depend on the store**: according to the pnpm documentation, recent versions run packages installed with `pnpm add -g` through a `links` folder inside the store by default, so deleting the whole store means reinstalling those global tools. The same applies to Bun's `globalStore` (off by default) when enabled: affected projects need `bun install` again.\n- **Yarn PnP projects read straight from the cache**: Yarn projects using Plug'n'Play have no `node_modules`; their dependencies are the zip files in the cache. After clearing the cache, run `yarn install` before starting such a project.\n\n## Manual cleanup commands {#manual-cleanup}\n\n### npm {#npm}\n\n```bash\n# Show the cache root; the default is ~\u002F.npm\nnpm config get cache\ndu -sh ~\u002F.npm\u002F_cacache ~\u002F.npm\u002F_npx\n# Verify the cache and garbage-collect unneeded data without clearing it\nnpm cache verify\n# Clear the _cacache download cache; node_modules in your projects is untouched\nnpm cache clean --force\n# Remove tools installed temporarily by npx; they are downloaded again on the next run\nrm -rf ~\u002F.npm\u002F_npx\n```\n\nnpm's cache is self-healing, and the [npm documentation](https:\u002F\u002Fdocs.npmjs.com\u002Fcli\u002Fv11\u002Fcommands\u002Fnpm-cache) says there is no reason to clear it other than reclaiming disk space. If an install fails, try `npm cache verify` first.\n\n### pnpm {#pnpm}\n\n```bash\n# Show the current store location, for example ~\u002FLibrary\u002Fpnpm\u002Fstore\u002Fv10\npnpm store path\ndu -sh \"$(pnpm store path)\"\n# Remove only packages that no project references\npnpm store prune\n# The metadata cache can be deleted outright; pnpm downloads it again as needed\nrm -rf ~\u002FLibrary\u002FCaches\u002Fpnpm\n```\n\nThe [pnpm documentation](https:\u002F\u002Fpnpm.io\u002Fcli\u002Fstore) notes that `pnpm store prune` has no side effects on your projects and recommends running it occasionally, not too often, because packages you just removed may be needed again soon. pnpm uses one store per disk: for projects on an external disk, the store is usually `.pnpm-store` at the root of that disk, and running `pnpm store path` inside such a project shows it.\n\n### Yarn {#yarn}\n\nYarn 1 and Yarn 2+ use different commands, so first run `yarn --version` to see which version is active in the current directory.\n\n```bash\n# Yarn 1: show and clear the global cache\nyarn cache dir\nyarn cache clean\n# Yarn 2 and later: run inside a project that uses it; clears only the global cache\nyarn cache clean --mirror\n```\n\n`yarn cache clean --all` also deletes the current project's local cache. If a project commits `.yarn\u002Fcache` to its repository (Zero-Installs), do not use `--all` in that project.\n\n### Bun and Corepack {#bun-corepack}\n\n```bash\n# Show Bun's global cache location\nbun pm cache\n# Clear Bun's global cache\nbun pm cache rm\n# Remove package manager versions downloaded by Corepack; they are fetched again when used\nrm -rf ~\u002F.cache\u002Fnode\u002Fcorepack\n```\n\n## Clean up with WashBear {#washbear}\n\nA **Standard Scan** in [Deep Cleanup](\u002Fdocs\u002Fdeep-clean) checks the default locations of these caches and lists them in two categories, depending on where they live:\n\n- **Developer tools**: **npm download cache**, **npx temporary tools**, and **Bun package cache**.\n- **User cache files**: **pnpm store cache** (the store plus the metadata cache), **Yarn download cache** (the global caches of Yarn 1 and Yarn 2+), **node-gyp build cache**, and **Node.js tooling cache** for downloads by Corepack, Electron, and similar tools. These items include folders under `~\u002FLibrary\u002FCaches`, which is why they appear here.\n\n**Smart recommendation** preselects the npm, npx, and node-gyp items; select the pnpm store, Yarn, Bun, and the Node.js tooling cache yourself if you want them. WashBear deletes the entire cache or store folder, which amounts to a full clear, not a `pnpm store prune` that removes only unreferenced packages. If you rely on pnpm global installs or have Yarn projects using PnP, read the caveats above before selecting these items.\n\n> [!NOTE]\n> WashBear only checks default locations, so caches you moved elsewhere and pnpm stores on other disks are not found. `node_modules` folders inside projects belong to the **Project build artifacts** category and are never preselected. Cleanup deletes files directly instead of moving them to the Trash, and the result is recorded in [Operation History](\u002Fdocs\u002Fgetting-started#history).\n\nTo see how large these caches are on your Mac, [download WashBear](\u002Fdownload) and run a scan; scanning alone never deletes anything. The demo below uses sample data, so its items, categories, and selections are only illustrative.\n\n::demo deepClean\n\n## FAQ {#faq}\n\n### Will my projects still work after I clear the caches? {#faq-projects-still-run}\n\nYes. Dependencies are already installed in each project's `node_modules`, and deleting a global cache does not change them; the next install just spends more time downloading. The exceptions are the Yarn PnP projects and pnpm global tools that run from the store, as described above.\n\n### How often should I clear them? {#faq-how-often}\n\nThere is no need to clear them on a schedule. Clear them when your disk is tight, or run `pnpm store prune` and `npm cache verify` every few months.\n\n### Why did deleting the pnpm store free less space than expected? {#faq-space-not-freed}\n\nBecause `node_modules` folders you still use reference the same data blocks. Remove `node_modules` from old projects you no longer use, and that space is actually released.\n",1793258439454]