Rimraf npm: Is It Still Worth Installing in 2025?

Rimraf npm is a small, actively maintained utility that recursively deletes files and directories — the programmatic equivalent of rm -rf — and it's still safe to use, but modern Node projects often no longer need it. The package currently sits at version 6.x and receives well over 130 million downloads a week, so it isn't going anywhere. What has changed is that Node.js added a native recursive delete, and older rimraf releases now emit deprecation warnings that confuse a lot of developers. This post explains what npm rimraf actually does, why those warnings appear, and how to decide whether to keep it.

What rimraf does and why it existed

rm -rf some/dir is a one-liner on Unix, but it isn't portable, and Node historically had no reliable cross-platform way to delete a directory tree. fs.rmdir only removed empty directories, and doing it recursively meant walking the tree yourself and handling the platform quirks — Windows file locks, EPERM races, symlinks, and busy files.

rimraf solved that. It exposes a single function that deletes a path and everything under it, retrying on transient errors, working the same on Linux, macOS, and Windows. Build tools lean on it constantly: cleaning a dist/ folder, wiping a cache, resetting a test fixture. That's why it ended up as a transitive dependency of thousands of packages, including large chunks of the toolchain most JavaScript projects already install.

Why you keep seeing rimraf deprecation warnings

If you've run npm install recently, you've probably seen something like:

npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory.
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported

These warnings trip people up because they look like a security alert. They aren't. The maintainer, Isaac Schlueter (who also created npm), deliberately marked old major versions as unsupported to push the ecosystem forward. rimraf v3 and earlier depend on old glob and the abandoned inflight module, which does leak memory. The warning is telling you that the old version is end-of-life, not that rimraf as a project is dead.

The catch: you usually didn't install that old rimraf directly. Some dependency deep in your tree pinned rimraf@3. Running npm ls rimraf shows you who:

npm ls rimraf

You can't always fix it yourself — the fix belongs to whichever package depends on the old version. This is a textbook case of transitive dependency drift, and it's exactly the kind of thing a dependency scanner surfaces. An SCA tool such as Safeguard can show you the full path from your app down to the deprecated rimraf@3 so you know which upstream package needs to bump.

Is rimraf a security risk?

The deprecation warning is a maintenance signal, not a known vulnerability. As of 2025, rimraf itself does not carry a widely reported critical CVE, and the current 6.x line is actively maintained. The genuine concern with any recursive-delete utility isn't a bug in the library — it's how your code calls it.

The dangerous pattern is passing an unsanitized or misconstructed path:

import { rimraf } from 'rimraf'

// If userInput is empty or '/', this is catastrophic
await rimraf(path.join(baseDir, userInput))

If userInput can be controlled by an attacker or is ever empty, you can end up deleting far more than intended — the JavaScript equivalent of the infamous rm -rf $VAR/ bug when $VAR is unset. rimraf added guards over the years (it refuses to delete / by default in recent versions), but you should never build a delete path from untrusted input without validating it first.

When you can drop rimraf entirely

Since Node.js 14.14.0, the standard library includes fs.rm with a recursive option, which does what rimraf does for the common case:

import { rm } from 'node:fs/promises'

await rm('dist', { recursive: true, force: true })

For synchronous code there's rmSync. If your project targets a modern Node version and you only need a straightforward recursive delete, you can remove the dependency and use the built-in. Fewer dependencies means a smaller attack surface and one less transitive tree to audit — which is a real, if modest, security win.

rimraf still earns its place when you need its extras: glob-pattern deletion, tuned retry behavior on Windows, or a consistent API across old and new Node versions in a library you ship to others.

Practical guidance

• If you depend on rimraf directly, upgrade to the current major version (npm install rimraf@latest) and the deprecation warning for your own usage disappears.
• If the warning comes from a transitive dependency, run npm ls rimraf, then update or replace the parent package. Don't try to force-resolve a newer rimraf under a package that expects the old API.
• For simple dist/ cleanup in a project on a recent Node, consider replacing rimraf with fs.rm({ recursive: true }) and dropping the dependency.
• Treat the warning as a prompt to review dependency freshness, not as an incident. Regular dependency hygiene, ideally automated, keeps these from piling up. Our dependency scanning overview covers how to track this at scale.

FAQ

Is rimraf deprecated?

No. Only rimraf versions prior to v4 are marked unsupported. The package as a whole is actively maintained, currently on the 6.x line, and downloaded well over 100 million times a week. The deprecation warnings you see refer to old major versions pulled in by other dependencies.

Should I replace rimraf with fs.rm?

If you're on Node 14.14.0 or newer and only need a basic recursive delete, fs.rm(path, { recursive: true, force: true }) is a drop-in replacement and lets you remove the dependency. Keep rimraf if you rely on glob patterns, its Windows retry tuning, or broad Node version support in a published library.

Why does npm warn about rimraf when I never installed it?

Because a package deep in your dependency tree depends on an old rimraf version. Run npm ls rimraf to find the parent. The fix is to update that parent package, not to install rimraf yourself.

Is npm rimraf a security vulnerability?

The deprecation notice is a maintenance signal, not a vulnerability. The real risk is passing an untrusted or empty path into rimraf, which can delete more than you intend. Validate any path built from user input before deleting.