npm install: Every Flag and Option Explained (2026)

npm install isn’t just about pulling in dependencies; it’s a finely tuned instrument that can dramatically affect your project’s build times, security, and even the very stability of your development environment.

Let’s see it in action. Imagine you’re in a project directory, and you run:

npm install express --save-exact

This command installs the express package, but with --save-exact, it records the exact version of express in your package.json’s dependencies field, not a range. This means subsequent installs will always use that precise version, preventing unexpected updates that could break your code.

Now, consider this:

npm install --production

This command, when run in a deployment environment, will only install packages listed in dependencies, completely skipping anything in devDependencies. This is crucial for keeping your production builds lean and secure, as development-specific tools shouldn’t be present on your live servers.

The real power of npm install comes from understanding how it manages your project’s dependencies and how you can influence that process. At its core, npm install reads your package.json file. This file is the manifest for your project, listing all the packages it needs and the specific versions or version ranges. When you run npm install, npm contacts the npm registry, fetches the required packages, and places them in the node_modules directory. It also generates a package-lock.json file (or npm-shrinkwrap.json) which is a snapshot of the exact versions of all packages installed, including their dependencies, sub-dependencies, and their sub-dependencies, all the way down. This lock file is the key to reproducible builds – ensuring that anyone installing your project gets the exact same set of dependencies.

Here’s a breakdown of some of the most impactful flags and options:

--save or -S: This is the default behavior for npm install <package> in modern npm versions. It installs the package and adds it to your dependencies in package.json. This means the package is required for your application to run in production.
```
npm install lodash -S
```
--save-dev or -D: Installs the package and adds it to your devDependencies in package.json. These are packages needed only during development, like testing frameworks (Jest, Mocha), build tools (Webpack, Babel), or linters (ESLint).
```
npm install jest -D
```
--save-exact or -E: As seen earlier, this flag ensures the exact version number of the installed package is recorded in package.json, rather than a version range (like ^4.17.21 or ~2.0.0). This is excellent for guaranteeing that your build won’t suddenly change due to a minor or patch version update in a dependency.
```
npm install react --save-exact
```
--global or -g: Installs a package globally on your system, making its executables available from any directory. This is typically used for command-line tools like nodemon, pm2, or create-react-app.
```
npm install -g nodemon
```
Note: Global installations bypass package.json and node_modules in your project directory.
--no-save: Installs a package but does not add it to package.json or package-lock.json. This is useful for one-off installations or for testing packages before committing them to your project’s dependencies.
```
npm install @babel/core --no-save
```
--production: As mentioned, this flag tells npm to only install packages listed in dependencies and ignore devDependencies. This is invaluable for CI/CD pipelines and production deployments.
```
npm install --production
```
--force: This is a powerful, and often risky, flag. It forces npm to fetch remote resources even if a local copy exists, and it can overwrite existing files. Use this with extreme caution, as it can lead to corrupted node_modules directories or unexpected behavior. It’s sometimes used as a last resort when npm ci or a clean install fails.
```
npm install --force
```
--legacy-peer-deps: In npm versions 7 and above, peer dependency conflicts are stricter. If you encounter many peer dependency warnings and your project seems to work fine, this flag tells npm to ignore them and proceed with the installation as if there were no conflicts. This can be a quick fix but might mask underlying issues.
```
npm install --legacy-peer-deps
```
--dry-run: This flag simulates the installation process without actually downloading or installing any packages. It’s useful for seeing what npm would do, which packages would be installed, and what changes would be made to your package.json and package-lock.json.
```
npm install express --dry-run
```
--omit <set>: This option allows you to explicitly exclude certain dependency sets during installation. The common sets are dev (equivalent to --production) and optional. For example, npm install --omit=dev is the same as npm install --production.
```
npm install --omit=dev
```
--install-links: When installing a local package (e.g., npm install ../my-local-package), this flag creates a symbolic link instead of copying the package. This is incredibly useful during development when you’re working on multiple related packages simultaneously, as changes in one package are immediately reflected in the other without needing to reinstall.
```
npm install ../my-local-library --install-links
```

The lock file (package-lock.json) is the silent hero here. It’s generated or updated every time you install, update, or uninstall packages. It ensures that your node_modules directory is consistent across different machines and at different times. When you run npm install without any package names, it reads package-lock.json and installs precisely those versions, guaranteeing reproducibility. If you ever need to ensure a completely clean and reproducible install, npm ci is your go-to command. It’s faster than npm install for CI environments because it skips package-lock resolution and directly installs from the lock file, failing if package.json and package-lock.json are out of sync.

The next hurdle you’ll likely encounter is understanding how semantic versioning (semver) interacts with npm’s default range specifiers like ^ and ~, and how to effectively manage complex dependency trees.