Fix: npm WARN deprecated - How to Handle Deprecated Package Warnings

The Error

You run npm install and see a wall of warnings:

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
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 are unsure whether to fix them, ignore them, or panic.

Why This Happens

A deprecated package is one whose maintainer has officially marked as outdated. This happens when:

• A better alternative exists. The maintainer recommends a different package (e.g., request → node-fetch or got).
• The package is unmaintained. The author stopped updating it and it may have known bugs or security issues.
• A major version replaced it. The old version still works but won’t receive updates (e.g., glob@7 → glob@9).
• The package was absorbed into Node.js core. Features like url.parse() or querystring are now built-in.

Deprecation warnings are informational. They do not break your build. Your code still works. But ignoring them indefinitely leads to security vulnerabilities, compatibility issues, and technical debt.

There are two types of deprecation warnings:

1. Direct dependencies — packages listed in your package.json. You control these.
2. Transitive dependencies — packages pulled in by your dependencies. You don’t directly control these.

The fix differs depending on which type you are dealing with.

Fix 1: Update Direct Dependencies

Check which of your direct dependencies are outdated:

npm outdated

This shows a table:

Package    Current  Wanted  Latest  Location
eslint     8.50.0   8.56.0  9.0.0   node_modules/eslint
rimraf     3.0.2    3.0.2   5.0.5   node_modules/rimraf
glob       7.2.3    7.2.3   10.3.0  node_modules/glob

• Wanted — the latest version matching your package.json semver range.
• Latest — the newest version available.

Update packages within your semver range:

npm update

To jump to the latest major version (which may have breaking changes):

npm install eslint@latest
npm install rimraf@latest

After updating, run your tests to make sure nothing broke. Major version bumps often require code changes. If your tests fail with lifecycle errors, check fixing npm ERR! code ELIFECYCLE.

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

npx npm-check-updates -u
npm install

This updates version ranges in package.json to match the latest versions. Always review the changes and test afterward.

Fix 2: Handle Transitive Dependency Deprecations

Most deprecation warnings come from transitive dependencies — packages your dependencies depend on. You cannot update these directly.

Find which direct dependency pulls in the deprecated package:

npm ls inflight

Output:

myproject@1.0.0
└─┬ some-tool@2.3.0
  └─┬ glob@7.2.3
    └── inflight@1.0.6

This shows some-tool depends on glob@7, which depends on inflight. Your options:

1. Update the direct dependency (some-tool) to a version that uses newer sub-dependencies.
2. Replace the direct dependency with an alternative that doesn’t use deprecated packages.
3. Use npm overrides to force a newer version of the transitive dependency (Fix 3).
4. Wait for the maintainer of some-tool to update their dependencies.

Check if a newer version of the direct dependency exists:

npm info some-tool versions

Fix 3: Use npm overrides to Force Updates

npm 8.3+ supports overrides in package.json. This forces a specific version of a transitive dependency:

{
  "overrides": {
    "glob": "^10.3.0",
    "rimraf": "^5.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 that changed in glob@10, it will crash at runtime. Test thoroughly after adding overrides.

For yarn, use resolutions instead:

{
  "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 deprecation warning but can introduce runtime errors if the forced version has a different API. Always run your test suite after adding overrides. If you’re seeing dependency resolution errors, check fixing npm ERESOLVE.

Fix 4: Find Replacement Packages

Some deprecated packages have well-known replacements:

The deprecation message often tells you the replacement. Read it carefully — it is usually right after the package name.

Fix 5: Run npm audit for Security Issues

Some deprecated packages also have security vulnerabilities. Check with:

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 that you cannot fix, check managing npm audit vulnerabilities for strategies.

Fix 6: Suppress Warnings (When Appropriate)

If you have reviewed the deprecation warnings and determined they are harmless (no security issues, the packages still work), you can suppress them:

Suppress all warnings during install:

npm install --loglevel=error

In CI/CD pipelines, this keeps the output clean:

- run: npm ci --loglevel=error

In .npmrc:

loglevel=error

This hides all warnings, not just deprecation notices. Use it only when you have a process for regularly reviewing dependencies (like automated updates).

Fix 7: Automate Dependency Updates

Manual dependency management doesn’t scale. Use automated tools to keep dependencies current:

Dependabot (GitHub):

Create .github/dependabot.yml:

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

Dependabot creates pull requests for outdated dependencies automatically.

Renovate (works on 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.

npm-check-updates (manual check):

npx npm-check-updates

This lists all available updates without changing anything. Add -u to update package.json.

When to Safely Ignore Deprecation Warnings

Not every deprecation warning requires immediate action:

• The deprecated package has no security vulnerabilities (check with npm audit).
• It is a transitive dependency and the parent package is actively maintained — they will update eventually.
• You are about to migrate away from the tool that uses the deprecated package (e.g., you’re switching build tools).
• The deprecation is cosmetic — the package still works perfectly but the author wants to push users to a rewrite. This is common with packages like glob where the old API is stable.

What you should not ignore:

• Security vulnerabilities flagged by npm audit.
• Packages marked as “this module leaks memory” or “known security issues.”
• Deprecations in packages you import directly — these you control and should update.

If deprecated packages are preventing your npm scripts from running at all, that’s a different issue. Check fixing npm missing script errors or npm cb() never called for those cases.

Still Not Working?

If deprecation warnings persist after updating:

Clear the npm cache and reinstall:

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

Check for multiple lockfile versions. If you have both package-lock.json and yarn.lock or pnpm-lock.yaml, npm might resolve dependencies differently than expected. Use only one package manager per project.

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

Pin Node.js and npm versions. Different npm versions handle deprecation warnings differently. Use .nvmrc or engines in package.json to ensure consistency across your team and CI/CD.

Accept that some warnings are permanent (for now). The npm ecosystem has deep dependency trees. A single widely-used package deprecating a dependency can cascade warnings across thousands of projects. If the warning is harmless and you cannot override it, document it and move on.