1. Search the projects you recognize
Old JavaScript projects can retain installed dependencies long after you stop using them. Begin with the directory where you keep repositories, rather than scanning the whole drive. This reduces unrelated results and makes each finding easier to connect to an actual project. Include old experiments only if you know where they live.
In Terminal, first change into that project directory. Then run: find . -type d -name node_modules -prune -print. This is a read-only listing. The dot means the current directory; confirm that location before running it. The prune option stops descending into a matched dependency tree, keeping the output more manageable.
2. Measure a folder before deciding
In Finder, open a returned path and use Get Info on node_modules. Alternatively, from the parent projects directory, run du -sh "./your-project/node_modules", replacing the example with the exact path you reviewed. Keep the quotes if names contain spaces. This command reports size without changing the folder.
Treat totals carefully when projects use shared package stores or linked files. Different tools may account for shared storage differently, so adding every folder size is not a guarantee of recoverable bytes. Check actual available space after one removal before extrapolating savings across all your projects.
3. Check that you can reconstruct dependencies
Keep package.json, the package manager’s lockfile, source code, configuration and any required local packages. Record the Node and package-manager versions from the project’s documentation. Check for manual edits inside node_modules, patch files, private registry access and dependencies that may no longer be downloadable.
For an npm project with a compatible package-lock.json or npm-shrinkwrap.json, npm ci performs a clean install. It requires agreement between the lockfile and package.json and removes an existing node_modules before installing. Use the project’s documented command and required flags; do not switch a pnpm or Yarn project to npm just for cleanup.
4. Remove one inactive dependency tree
Stop the project’s development server, watchers and tests. In Finder, move only the reviewed node_modules folder to Trash. Leave the project root and hidden configuration intact. If you found files you modified manually, preserve those changes outside generated dependencies before proceeding.
For a project you need to retain, verify a fresh dependency install and the project’s normal build or test command when practical. Installation can execute package scripts and use the network, so perform it only for projects you trust. For archival projects that cannot be reconstructed, keep a verified backup instead of assuming a lockfile is sufficient.
5. Distinguish dependencies from package caches
The npm download cache is separate from each project’s node_modules. npm documents its cache as self-healing and provides npm cache verify for checking it; repeatedly clearing that cache is not the same as removing inactive project dependencies. Leave shared package stores alone unless you understand the package manager’s own cleanup workflow.
Review Trash before emptying it, then compare available Mac space. Expect dependencies to return when you resume work on a project. Keep the projects you use frequently ready to run, and review inactive repositories when storage pressure justifies the time needed to restore them later.
References & further reading
These guides combine the linked official guidance with ClearDisk’s documented behavior. Your files and app settings determine the right next step.