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

The Wall of Warnings

I have seen this question asked a hundred times in different forms: “I just ran npm install on a fresh checkout and 30 lines of red text scrolled by, is my project broken?” Almost always the answer is no, but the warnings do matter for different reasons than most developers assume. You run npm install and see a wall of:

npm WARN deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Use `lru-cache` for this purpose.
npm WARN deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm WARN deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm WARN deprecated @humanwhocodes/config-array@0.11.14: Use @eslint/config-array instead
npm WARN deprecated @humanwhocodes/object-schema@2.0.3: 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.

Quick Reference Before You Dive In

If you arrived here from Google with a wall of npm WARN deprecated, the five facts that resolve roughly 90 percent of cases:

1. deprecated is NOT a security vulnerability. It is a maintainer marker that says “use something newer.” Run npm audit separately to find actual security issues. The npm deprecated documentation and the npm overrides reference are the canonical sources.
2. Most warnings come from transitive dependencies, not your own package.json. Use npm ls <package> to find the chain. Updating the top-level parent (often ESLint or Jest) clears multiple warnings at once; npm update alone usually does not, because it respects semver and the parent has not loosened its pin.
3. overrides (npm 8.3+) forces a specific version of a transitive dependency. Add it to package.json, delete node_modules and package-lock.json, reinstall. Yarn calls this resolutions; pnpm calls it pnpm.overrides; Bun uses overrides like npm. Overrides can break consumers that depend on the old API; test thoroughly.
4. The (node:NNNN) DeprecationWarning: ... punycode message is different. That is a Node.js BUILT-IN deprecation, not an npm package warning. It appears at runtime, not at install. Suppress with NODE_OPTIONS=--no-deprecation for now; the long-term fix is upstream packages updating.
5. npm WARN deprecated is the noisiest because npm prints inline. Yarn Berry, pnpm, and Bun show the same data quieter. Switching tools does not fix the deprecation; it just rearranges the display. The underlying package is still deprecated; query with npm view <pkg> deprecated.

The rest of this article walks through each warning in detail, plus the failure modes most other guides skip.

What “Deprecated” Actually Means Here

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

inflight@1.0.6: “leaks memory”

npm WARN deprecated inflight@1.0.6: 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).

glob@7.2.3: “prior to v9 are no longer supported”

npm WARN deprecated glob@7.2.3: 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.

rimraf@3.0.2: “prior to v4 are no longer supported”

npm WARN deprecated rimraf@3.0.2: 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. Updating ESLint or your other build tools is usually 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/config-array@0.11.14: Use @eslint/config-array instead
npm WARN deprecated @humanwhocodes/object-schema@2.0.3: 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 abbrev@1.1.1: Package no longer supported.
npm WARN deprecated are-we-there-yet@2.0.0: ...
npm WARN deprecated npmlog@5.0.1: ...
npm WARN deprecated gauge@3.0.2: ...

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 Direct Updates Sometimes Do Not Help

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.

When to Use Which Fix

The next sections cover the fixes in detail. The table below maps your situation to the recommended fix.

If multiple rows apply, pick the topmost one.

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:

myproject@1.0.0
└─┬ eslint@8.57.0
  └─┬ glob@7.2.3
    └── inflight@1.0.6

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.

In my own projects I run npx npm-check-updates (or ncu) every couple of months to see what is upstream of my pinned versions. It rewrites package.json for you, which is dangerous on autopilot, but combined with a passing test suite it is the fastest way to clear a backlog of deprecation warnings. The workflow:

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. Overrides also frequently trigger npm ERESOLVE dependency tree errors on the next install; read that guide if your override starts failing the resolver.

For yarn, use resolutions:

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

For pnpm, use pnpm.overrides:

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

I have shipped an override that quietly broke production exactly once. The package I forced from v2 to v3 had a renamed export; the build succeeded because the override was applied at install time, not at type-check time, and the broken import only ran on an edge code path that escaped CI. Adding an override silences the warning but can introduce real runtime errors if the forced version changed its API. Run the full test suite, then deploy to staging, before you trust an override in production.

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

How Other Package Managers Handle Deprecation

npm WARN deprecated is npm’s specific phrasing. Yarn, pnpm, and Bun all read the same deprecated field from the npm registry but surface it differently, and the surface area is where most confusion comes from.

Yarn Classic (1.x)

Yarn 1 prints warnings during install in the same way as npm but groups them under a warning prefix instead of npm WARN. The warning text comes verbatim from the registry, so the package name and message match npm exactly. Yarn 1 also uses resolutions to override transitive versions; the syntax differs from npm’s overrides, but the effect is the same. Yarn 1 is itself deprecated (the maintainers recommend Yarn Berry) so if you see deprecation warnings on Yarn 1 itself, that is the meta-warning the project sometimes prints on install.

Yarn Berry (2.x / 3.x / 4.x)

Yarn Berry intentionally suppresses noisy install output. Deprecation warnings appear only when you run yarn install --check-cache or explicit audit commands. Berry’s Plug’n’Play (PnP) mode resolves dependencies differently from node_modules, so transitive deprecations are still recorded in yarn.lock but the user-facing log is much shorter. Use yarn explain peer-requirements and yarn npm audit to inspect what npm would have warned about.

pnpm

pnpm shows deprecation warnings near the end of the install summary, prefixed with deprecated and grouped by package. Because pnpm uses a content-addressable store with a flat symlink layout under node_modules/.pnpm, the same deprecated package is only listed once even if a hundred consumers pull it in, which makes the warning list much shorter than npm’s. The pnpm.overrides field in package.json plays the same role as npm overrides and Yarn resolutions.

Bun

Bun’s installer (bun install) reads the npm registry’s deprecated field but prints warnings only for direct dependencies by default. Transitive deprecations are recorded silently in bun.lockb and surface only when you run bun outdated or bun why <package>. Bun is the most permissive of the four: quiet by default, on the assumption that you will inspect deprecations when you want to.

What gets captured in the lockfile

Every modern lockfile stores the resolved version of each dependency, not the deprecation status. That means a package deprecated after your lockfile was generated will not show a warning until you re-run install or refresh the lockfile. Run npm install --package-lock-only (or yarn install --mode update-lockfile, pnpm install --lockfile-only) to re-check deprecations without writing to node_modules.

Suppressing deprecation output

Registry-level deprecation API

The npm registry exposes deprecation through https://registry.npmjs.org/<package>; every version has a deprecated string. All four package managers read the same endpoint, which is why the messages are identical across tools. You can deprecate your own published package with npm deprecate <package>@<version> "message", and all four installers will start surfacing that message the next time their cache is invalidated.

The takeaway: npm shows the most warnings because it shows them inline during every install. The other tools have not silenced the data; they have just moved it. If you want a quiet install in any tool, the underlying deprecation is still recorded somewhere you can query.

Edge Cases That Still Bite

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.

Your .npmrc is forcing an old registry mirror. Corporate proxies and private registries sometimes cache the package tarball but not the metadata refresh that carries the deprecated field. Inspect the effective registry with npm config get registry, and compare a package’s metadata between your mirror and the public registry with npm view <pkg> deprecated --registry=https://registry.npmjs.org. If the public registry reports a deprecation but your mirror does not, ask the registry admin to enable metadata sync.

An override is being silently ignored. overrides in package.json only apply if the package manager you’re running is recent enough: npm 8.3+, pnpm 7+, Yarn Berry. Older versions parse the field but do not act on it. Confirm by running npm ls <package> after install and checking the resolved version matches your override. If it does not, upgrade your package manager, not your dependencies.

The warning comes from node_modules you no longer use. A stale node_modules directory can keep deprecated packages alive long after you removed them from package.json. npm prune removes packages that are no longer listed in package.json, but only inside the current install; it does not refresh metadata. After a major dependency change, the safest sequence is to delete node_modules, delete package-lock.json, and run npm install from scratch.

What Other Tutorials Get Wrong About npm Deprecation Warnings

Most npm tutorials list the same fixes but frame them in ways that produce subtle bugs.

They equate deprecated with “vulnerable.” Deprecation is a maintainer flag for “use something newer,” not a CVE. Many deprecated packages still work correctly and have no security issues. npm audit reports vulnerabilities; npm WARN deprecated reports maintainer preference. Conflating them either creates panic where there is none or hides real audit findings under deprecation noise.

They recommend npm audit fix --force as a default. The --force flag may upgrade packages to new majors with breaking changes. Some tutorials present this as the universal solution; it should be the last resort. Use plain npm audit fix first, review the changes, and only escalate to --force after reading the diff.

They omit the overrides API version requirement. overrides in package.json only works on npm 8.3+, pnpm 7+, and Yarn Berry. Older versions parse the field silently without applying it, so the warning persists and the reader assumes the override “did not work.” The fix is to upgrade the package manager, not the dependency.

They tell users to update direct dependencies and stop. Most deprecation warnings come from TRANSITIVE deps. Updating direct deps with npm update only nudges within semver ranges and almost never clears transitive warnings. The correct mental model is: identify the parent with npm ls, then bump the parent’s major version.

They treat npm WARN deprecated and Node.js DeprecationWarning identically. They are different categories. npm WARN deprecated punycode would be an install-time package warning; (node:NNNN) [DEP0040] DeprecationWarning is a runtime built-in deprecation. The suppressions differ: --loglevel=error for the former; NODE_OPTIONS=--no-deprecation for the latter. Tutorials that group them together send readers to the wrong flag.

They miss the registry-mirror caveat. Corporate proxies and private registries sometimes cache tarballs but not the metadata refresh that carries the deprecated field. The warning appears or disappears differently from the public registry. Inspect with npm view <pkg> deprecated --registry=https://registry.npmjs.org to compare.

Frequently Asked Questions

Is a deprecated package a security vulnerability?

No. Deprecation is a maintainer flag meaning “use something newer.” Many deprecated packages still work and have zero known CVEs. Security vulnerabilities are reported separately by npm audit. Treat the two as independent concerns: clear deprecations on your timeline, fix audit findings immediately.

Why does npm update not remove the warnings?

npm update updates packages within the semver range you have pinned. If eslint@^8 pins to glob@7, npm update does not bump ESLint to 9 because that crosses a major-version boundary. To clear transitive deprecation warnings, you usually need npm install eslint@latest (explicit major bump) or npm overrides.

Can I just delete package-lock.json and reinstall to fix it?

That works only when newer compatible versions exist within your current semver ranges. If your package.json pins eslint: "^8.0.0", deleting the lockfile reinstalls the latest 8.x, which still uses glob@7. The fix is to update the pin, not just refresh the lockfile.

Should I use npm overrides for every deprecation?

No. Use overrides when the parent package is slow to update and you cannot wait. Risks: the forced version may have a different API than the parent expects, causing runtime failures. Always test thoroughly and avoid overriding packages used in hot code paths without a CI signal that exercises them.

What is the difference between deprecation and removal?

Deprecation is a soft signal: the package still installs, still runs, still works. Removal is hard: the package is gone from the registry. The npm registry does not actually remove packages once published (unpublishing is heavily restricted since the left-pad incident); deprecation is the strongest signal a maintainer can send.

How do I tell if a deprecation warning matters for my project?

Three questions: (1) Does npm audit flag the package as vulnerable? Then yes. (2) Is your code using the deprecated package directly (not transitively)? Then yes; pick a replacement. (3) Is the parent package actively maintained and likely to update soon? Then no; document and revisit in a quarter.

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 ENOENT no such file for those cases.