What causes "Failed to remove node_modules" in vercel/turborepo?

Close all processes touching the repo (editors, watch mode, terminals cd'd into it) and rerun

vercel/turborepo · error · ConvertError

error_removing_node_modules

error_removing_node_modules

Error message

Failed to remove node_modules

What it means

Identical cleanup step to bun's, in the npm conversion path: fs.rm(recursive, force) over root and workspace node_modules directories; any rejection is rethrown as ConvertError type error_removing_node_modules. The conversion aborts before install because stale node_modules from the old manager would corrupt the new one.

Source

Thrown at packages/turbo-workspaces/src/managers/npm.ts:205

  });

  if (!options?.dry) {
    fs.writeJSONSync(project.paths.packageJson, packageJson, { spaces: 2 });

    // collect all workspace node_modules directories
    const allModulesDirs = [
      project.paths.nodeModules,
      ...project.workspaceData.workspaces.map((w) => w.paths.nodeModules)
    ];
    try {
      logger.subStep(`removing "node_modules"`);
      await Promise.all(
        allModulesDirs.map((dir) =>
          fs.rm(dir, { recursive: true, force: true })
        )
      );
    } catch (err) {
      throw new ConvertError("Failed to remove node_modules", {
        type: "error_removing_node_modules"
      });
    }
  }
}

/**
 * Clean is called post install, and is used to clean up any files
 * from this package manager that were needed for install,
 * but not required after migration
 */
// eslint-disable-next-line @typescript-eslint/require-await -- must match the clean type signature
async function clean(args: CleanArgs): Promise<void> {
  const { project, logger, options } = args;

  logger.subStep(
    `removing ${path.relative(project.paths.root, project.paths.lockfile)}`
  );

View on GitHub (pinned to f9245100cf)

Solutions

Close all processes touching the repo (editors, watch mode, terminals cd'd into it) and rerun
Retry after a short delay - Windows EBUSY is often transient once handles release
Remove manually then rerun conversion: npx rimraf node_modules plus each workspace's node_modules
On Windows enable long path support or move the repo shallower if path length is the cause
In CI, ensure no cached node_modules is mounted read-only

Defensive patterns

Strategy: retry

Validate before calling

import { accessSync, constants } from "node:fs";

function nodeModulesRemovable(paths: string[]): boolean {
  return paths.every((p) => {
    try { accessSync(p, constants.W_OK); return true; } catch { return false; }
  });
}
// pre-validate project.paths.nodeModules + workspace node_modules before convert

Try / catch

try {
  await convert({ project, convertTo: npmDetails, logger });
} catch (err) {
  if (err instanceof ConvertError && err.type === "error_removing_node_modules") {
    // EBUSY/EPERM: kill processes locking the tree, npx rimraf node_modules, retry once
  }
  throw err;
}

Prevention

Shut down watch mode and editors touching node_modules before converting
Enable Windows long-path support or keep repos near the drive root
Retry once after a delay - Windows handle release is often delayed

When it happens

Trigger: Converting to/from npm while node_modules is locked or undeletable: EBUSY/EPERM on Windows (files open in another process), EACCES from wrong ownership in containers, ENOTEMPTY from concurrent modification, or long-path failures on Windows without long path support enabled.

Common situations: Windows with VS Code/dev servers open, antivirus scanners holding handles, CI volumes with odd permissions, path-length overflow with deeply nested deps when long paths are disabled.

Related errors

AI-assisted analysis of vercel/turborepo@f9245100cf (2026-08-17). Data as JSON: /api/errors/0917844b8647bf84. Report an issue: GitHub.