VisCommandsvis clean

vis clean

Remove node_modules (and optionally lockfiles and stale package directories) from the workspace

vis clean

Remove node_modules from every workspace project, and optionally lockfiles and stale package directories. Removal is symlink-safe (it never follows symlinks or Windows junctions into their targets).

The workspace root's own node_modules is always removed last — package node_modules symlink into the root store and the running vis resolves its own binary and native addon from the root, so clearing the root first could pull those out mid-run.

Usage

vis clean [options]

Examples

# Remove every node_modules directory in the workspace
vis clean

# Also remove lockfiles (pnpm-lock.yaml, package-lock.json, …)
vis clean --lockfile

# Also remove stale workspace directories that have no package.json
vis clean --empty-packages

# Preview what would be removed without deleting anything
vis clean --dry-run

Options

OptionAliasDefaultDescription
--lockfile-lfalseAlso remove lockfiles (pnpm-lock.yaml, package-lock.json, npm-shrinkwrap.json, yarn.lock, bun.lock, bun.lockb)
--empty-packages-efalseAlso remove directories that match a workspace pattern but have no package.json
--dry-runfalseShow what would be removed without acting

--empty-packages

Workspace patterns such as packages/* occasionally leave behind directories that no longer contain a package.json — a half-deleted package, a renamed folder, a scratch checkout. Installs and task discovery silently skip them, so they linger. --empty-packages removes any directory that matches a configured workspace pattern (read from pnpm-workspace.yaml, falling back to package.json#workspaces) but carries no package.json.

A directory that still contains a package further down — e.g. a grouping folder packages/group under a packages/** pattern with a real packages/group/pkg/package.json — is never removed, so you can't accidentally delete a valid package.

Support

Contribute to our work and keep us going

Community is the heart of open source. The success of our packages wouldn't be possible without the incredible contributions of users, testers, and developers who collaborate with us every day.Want to get involved? Here are some tips on how you can make a meaningful impact on our open source projects.

Ready to help us out?

Be sure to check out the package's contribution guidelines first. They'll walk you through the process on how to properly submit an issue or pull request to our repositories.

Submit a pull request

Found something to improve? Fork the repo, make your changes, and open a PR. We review every contribution and provide feedback to help you get merged.

Good first issues

Simple issues suited for people new to open source development, and often a good place to start working on a package.
View good first issues