Introduction

The --save flag in npm install used to mean "add this package to dependencies in package.json." That was once necessary, but in modern npm it is already the default behavior.

So the short answer is: --save is mostly historical now. It still communicates intent to humans reading the command, but npm no longer needs it for normal dependency installation.

What --save Originally Did

Before npm 5, installing a package did not automatically update package.json. If you wanted the dependency recorded for the project, you had to say so explicitly:

npm install lodash --save

That added an entry like this:

1{
2  "dependencies": {
3    "lodash": "^4.17.21"
4  }
5}

Without --save, the package could be installed in node_modules without becoming part of the project's declared dependency list.

That mattered because teammates or CI systems would not know to install it later.

What Happens in Modern npm

Starting with npm 5, saving to dependencies became the default:

npm install lodash

This now does the same normal thing that npm install lodash --save used to do. The package is installed and recorded under dependencies.

That is why many modern projects do not bother with --save. It is redundant in current npm behavior.

Related Flags Still Matter

Even though plain --save is mostly unnecessary, the related flags are still important because they control where the dependency is recorded.

For development-only tools:

npm install jest --save-dev

This writes to devDependencies, which is the right place for test runners, linters, build tooling, and similar packages that the app does not need at runtime.

For optional dependencies:

npm install fsevents --save-optional

And if you explicitly do not want to save a package at all:

npm install lodash --no-save

So while --save itself faded into the background, the idea of choosing the correct dependency section is still very relevant.

Why the Distinction Matters

package.json is not just a shopping list. It tells everyone else how the project should be installed.

Choosing the right section affects:

• what gets installed in production
• what is available in local development
• how deployment systems treat the package
• how other developers understand the role of the dependency

For example, putting a test library into dependencies instead of devDependencies may unnecessarily increase production install size and complicate deployment.

A Practical Example

Suppose you are building a Node service that uses Express at runtime and ESLint only during development.

The correct commands are:

npm install express
npm install eslint --save-dev

That leads to a package.json with a clean separation between runtime and development concerns. That separation is more important than whether you typed the now-redundant --save on the Express command.

Common Pitfalls

• Thinking --save is still required in modern npm for ordinary dependencies.
• Forgetting that --save-dev still matters because it changes the dependency section.
• Installing a package with --no-save and then being surprised when teammates do not get it.
• Putting build tools in dependencies instead of devDependencies.
• Assuming all package managers behave exactly like npm. Similar flags can differ across tools.

Summary

• '--save used to add installed packages to dependencies in package.json.'
• In npm 5 and later, that behavior became the default.
• For ordinary dependencies, npm install package is usually enough now.
• The more important modern distinction is between dependencies, devDependencies, and other sections.
• '--save-dev, --save-optional, and --no-save still have meaningful uses.'