Fix: npm WARN deprecated — inflight, glob, rimraf, and Other Package Warnings

The Error

You run npm install and see a wall of warnings:

npm WARN deprecated [email protected]: This module is not supported, and leaks memory. Do not use it. Use `lru-cache` for this purpose.
npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm WARN deprecated [email protected]: Rimraf versions prior to v4 are no longer supported
npm WARN deprecated @humanwhocodes/[email protected]: Use @eslint/config-array instead
npm WARN deprecated @humanwhocodes/[email protected]: Use @eslint/object-schema instead

The install completes, but the warnings pile up. Some projects show dozens of them. You’re unsure whether to fix them, ignore them, or panic.

Short answer: Most of these are safe to ignore right now. They come from your dependencies’ dependencies — packages you don’t control. The one exception is anything flagged by npm audit as a security vulnerability.

Why This Happens

A deprecated package is one whose maintainer has officially marked as outdated. npm shows the warning because your dependency tree includes that package — usually not from your own package.json, but from a package your packages depend on.

There are two types:

1. Direct dependencies — packages listed in your own package.json. You control these and should update them.
2. Transitive dependencies — packages pulled in by your dependencies. You can’t directly control these.

The vast majority of npm WARN deprecated messages you’ll see are transitive. That’s why running npm update doesn’t make them go away.

The Most Common Warnings Explained

[email protected] — “leaks memory”

npm WARN deprecated [email protected]: This module is not supported, and leaks memory. Do not use it. Use `lru-cache` for this purpose.

Is it dangerous? Not for most projects. inflight is a tiny caching utility used deep inside glob@7, graceful-fs, and related packages. The “leaks memory” warning sounds alarming, but in practice this is only a problem in long-running servers that process millions of file operations. A typical dev tool using it briefly won’t accumulate meaningful memory usage.

Where it comes from: Almost always from glob@7, which is used by older versions of Jest, ESLint, webpack, and hundreds of other tools.

Fix: Update the parent tool that pulls in glob@7. For ESLint, update to ESLint 9. For Jest, update to Jest 29+. If you can’t, add an override (see Fix 3).

[email protected] — “prior to v9 are no longer supported”

npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported

Where it comes from: ESLint 8.x, older Jest versions, many build tools. glob@7 was the standard for years and it’s deeply embedded in the ecosystem.

Is it a problem? No immediate issue. glob@7 still works. The maintainer is pushing people toward v9+ which has a different (Promise-based) API, but v7 is stable.

Fix: If it’s from ESLint, updating ESLint to v9 eliminates both the glob and inflight warnings at once. If it’s from another tool, check npm ls glob to find the parent.

[email protected] — “prior to v4 are no longer supported”

npm WARN deprecated [email protected]: Rimraf versions prior to v4 are no longer supported

Where it comes from: ESLint 8.x, create-react-app, older build tooling.

Is it a problem? No. rimraf@3 still works fine on all supported Node.js versions. The author updated to v4+ with a native ESM API but the old version isn’t broken.

Fix: Same as glob — usually updating ESLint or your other build tools is the root fix. Or use Node’s built-in fs.rm({ recursive: true }) if you’re using rimraf directly.

@humanwhocodes/config-array and @humanwhocodes/object-schema

npm WARN deprecated @humanwhocodes/[email protected]: Use @eslint/config-array instead
npm WARN deprecated @humanwhocodes/[email protected]: Use @eslint/object-schema instead

Where it comes from: ESLint 8.x. Nicholas Zakas (ESLint’s creator) moved these packages to the @eslint/ scope when ESLint 9 was released.

Fix: Update ESLint to v9:

npm install eslint@latest --save-dev

Note that ESLint 9 uses a new flat config format (eslint.config.js) instead of .eslintrc. If you’re not ready to migrate the config, use the compatibility mode:

// eslint.config.js — compatibility shim for ESLint 9
import { FlatCompat } from "@eslint/eslintrc";
const compat = new FlatCompat();

export default [
  ...compat.extends("eslint:recommended"),
];

punycode — Node.js built-in deprecation

(node:12345) [DEP0040] DeprecationWarning: The `punycode` module is deprecated.

This is different — it’s a Node.js built-in deprecation, not an npm package deprecation. It appears in Node 21+ because punycode is being removed from Node’s standard library.

Where it comes from: Often from jest, whatwg-url, or packages that use IDN (internationalized domain names).

Fix: This is a runtime warning, not an install-time warning. To suppress it in Node 21+:

node --no-deprecation your-script.js
# or
NODE_OPTIONS=--no-deprecation npm test

The long-term fix is for the packages pulling in punycode to update — most are actively working on it.

abbrev, are-we-there-yet, npmlog, gauge

npm WARN deprecated [email protected]: Package no longer supported.
npm WARN deprecated [email protected]: ...
npm WARN deprecated [email protected]: ...
npm WARN deprecated [email protected]: ...

Where it comes from: Older versions of node-gyp, which is pulled in by packages with native C++ addons (like bcrypt, sharp, node-sass).

Fix: Update the package that uses native extensions. If you’re on node-sass, migrate to sass (the pure-JS Dart Sass implementation):

npm uninstall node-sass
npm install sass --save-dev

Why This Happens

npm’s resolution algorithm finds the highest version of each package that satisfies all constraints. When a popular tool like ESLint 8 requires glob@7, that requirement cascades down to everything that depends on ESLint — including your dev tools, your linters, and your test runners. Upgrading the direct dependency (ESLint) is the only real fix for these transitive warnings.

Fix 1: Identify Which Package Is Responsible

Before doing anything, find where the deprecated package is coming from:

npm ls inflight
npm ls glob
npm ls rimraf

Output shows the full dependency chain:

[email protected]
└─┬ [email protected]
  └─┬ [email protected]
    └── [email protected]

Now you know: updating ESLint fixes all three warnings at once.

Fix 2: Update Direct Dependencies

Check which of your direct dependencies are outdated:

npm outdated

Update packages within your semver range:

npm update

To jump to the latest major version:

npm install eslint@latest --save-dev
npm install rimraf@latest --save-dev

After updating, run your tests. Major version bumps often have breaking changes.

Pro Tip: Use npx npm-check-updates (or ncu) to see all available updates and update your package.json automatically:

npx npm-check-updates -u
npm install

Always review the diff and test afterward.

Fix 3: Use npm overrides to Force Updates

If you can’t update the parent package, npm 8.3+ supports overrides in package.json to force a specific version of a transitive dependency:

{
  "overrides": {
    "glob": "^10.3.0",
    "rimraf": "^5.0.0",
    "inflight": "npm:lru-cache@^10.0.0"
  }
}

Then reinstall:

rm -rf node_modules package-lock.json
npm install

Warning: Overrides can break packages that depend on the old API. If some-tool uses glob@7 API features removed in glob@10, it will crash at runtime. Test thoroughly.

For yarn, use resolutions:

{
  "resolutions": {
    "glob": "^10.3.0"
  }
}

For pnpm, use pnpm.overrides:

{
  "pnpm": {
    "overrides": {
      "glob": "^10.3.0"
    }
  }
}

Common Mistake: Adding overrides without testing. An override silences the warning but can introduce runtime errors if the forced version has a different API. Always run your test suite after adding overrides.

Fix 4: Replacement Packages for Direct Dependencies

If you’re using these deprecated packages directly in your own code, switch to modern alternatives:

Fix 5: Check for Actual Security Issues

Deprecation ≠ security vulnerability. Check separately:

npm audit

Fix automatically where possible:

npm audit fix

For breaking changes that audit fix won’t apply automatically:

npm audit fix --force

Warning: --force may upgrade packages to new major versions with breaking changes. Review the output before running it. If npm audit shows vulnerabilities in transitive dependencies you cannot fix, read managing npm audit vulnerabilities.

Fix 6: Suppress Warnings in CI

If you’ve reviewed the warnings and confirmed they’re harmless, suppress them in CI to keep output readable:

npm ci --loglevel=error

In a GitHub Actions workflow:

- name: Install dependencies
  run: npm ci --loglevel=error

In .npmrc (applies everywhere):

loglevel=error

This hides all warnings, not just deprecation notices. Only use it when you have a process for regularly reviewing dependencies.

Fix 7: Automate Dependency Updates

Manual dependency management doesn’t scale. Set up automated tools:

Dependabot (GitHub) — create .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

Renovate (GitHub, GitLab, Bitbucket) — add renovate.json:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"]
}

Renovate is more configurable than Dependabot and groups related updates together.

When to Safely Ignore Deprecation Warnings

Not every deprecation warning needs immediate action. It’s safe to ignore a warning when:

• npm audit shows no security vulnerabilities for that package
• It’s a transitive dependency and the parent is actively maintained (they’ll update eventually)
• You’re already planning to migrate away from the tool that pulls it in
• The deprecated package still works correctly and the deprecation is just the author recommending a newer version (common with glob, rimraf)

You should not ignore:

• Anything flagged by npm audit as a vulnerability
• Packages explicitly described as “leaks memory in production servers” if you’re running a high-load server
• Deprecations in packages you import directly in your code — these you fully control

Still Not Working?

Warnings persist after updating:

npm cache clean --force
rm -rf node_modules package-lock.json
npm install

Multiple lockfiles. If you have both package-lock.json and yarn.lock, npm may resolve dependencies differently than expected. Use one package manager per project.

Monorepo / workspace issues. In a monorepo, each workspace has its own dependency tree. Run npm outdated --workspaces to check all workspaces at once.

Some warnings are permanent (for now). The npm ecosystem has deep dependency trees. A single widely-used package deprecating a dependency cascades warnings across thousands of projects. If the warning is harmless and you cannot override it, document it and move on. The ecosystem will catch up — it always does.

If deprecated packages are preventing your npm scripts from running at all, that’s a separate issue. Check fixing npm missing script errors or npm ERR! code ENOENT for those cases.