Install Node Package with npm: A 2026 Guide

To install a node package, open your terminal in your project folder and run:

npm install <package-name>

npm fetches the package from the registry, unpacks it into a node_modules folder, and records it as a dependency in your package.json. Every time you install node package dependencies this way, npm also writes the exact resolved versions to package-lock.json, which is what keeps builds reproducible later. If the project already has a package.json full of dependencies, running npm install with no arguments installs all of them at once. For command-line tools you want available system-wide, add the -g flag.

None of that works, of course, unless Node.js and npm are actually on your machine. And how you install those matters more than most tutorials admit. So here's the whole chain: getting Node and npm set up properly, installing packages the right way, dealing with npm 12's new security defaults, and fixing the errors you'll actually run into.

First, check what you already have

Before installing anything, check your current setup:

node -v
npm -v

If both commands return version numbers, you're ready to install packages right now. If you get "command not found" or a version that's years old (npm 8 or below is a sign your Node install is ancient), read the next section.

One quick note on versions: Node releases an even-numbered Long Term Support (LTS) line every year. As of early 2026, Node 22 is the current LTS and Node 24 is in active LTS support. For production work, stick to an LTS line. Odd-numbered releases move too fast.

Installing Node.js and npm: use a version manager, not the installer

Here's my honest opinion after years of breaking dev machines: the official Node.js installer from nodejs.org is the worst way to install Node on a machine you care about. It dumps npm into a directory that needs elevated permissions for global installs, which is exactly why you later see EACCES permission errors when you run npm install -g anything. The npm documentation itself says this: they strongly recommend a version manager and explicitly warn against the system installer for this reason, and that guidance was reaffirmed in the npm Docs install page updated on 2026-09-12.

So use a version manager. It lets you install multiple Node versions side by side and switch between them per project, which you will eventually need when one project wants Node 18 and another wants Node 22.

macOS and Linux: use nvm (Node Version Manager).

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash

Then close and reopen your terminal, and install a version:

nvm install --lts
nvm use --lts

Windows: use nvm-windows, which is a separate project with a similar purpose. Download the setup from its releases page and run:

nvm install lts
nvm use lts

Microsoft's own Windows setup guidance on Microsoft Learn points developers at nvm-windows for installing Node.js and npm, which tells you how mainstream this approach has become.

Version managers also sidestep the need for sudo. If you ever find yourself typing sudo npm install -g, stop. That's a symptom of a system-level Node install, and it'll cause subtle permission problems down the road. Reinstall through a version manager instead.

How to install node package dependencies: the commands that matter

Once Node and npm are in place, these are the commands you'll use daily.

Set up a project first (if starting from scratch):

mkdir my-app && cd my-app
npm init -y

The -y flag accepts all defaults so you can edit package.json later.

Install a package as a production dependency:

npm install express

Install a package as a dev dependency (testing tools, bundlers, linters):

npm install --save-dev eslint

Install a global tool:

npm install -g typescript

Install everything listed in package.json:

npm install

Install a specific version or range:

npm install react@18.3.1
npm install lodash@^4.17.21

A few details worth knowing. npm i is shorthand for npm install; both are identical, so the People-Also-Ask question about "npm i vs npm install" has a boring answer: they're the same command. Since npm 5, installed packages are saved to package.json automatically, so you no longer need the old --save flag.

npm also generates a package-lock.json that pins the exact versions it resolved. Commit that file to version control. Without it, two installs of the same package.json can produce different dependency trees, and I've lost count of how many "works on my machine" bugs traced back to a missing or ignored lockfile. When you install node package versions from a range like ^4.17.21, the lockfile is what records exactly what you got.

Where do the files go? Locally installed packages land in node_modules in your project folder. Global packages live in a separate location (on nvm-based setups, inside your user's .nvm directory). To find your global path, run npm root -g.

npm 12 no longer runs install scripts automatically

If you upgraded npm recently and an install suddenly stopped working, this is probably why.

What changed: when you install node package code with npm 12 (released August 2026), lifecycle scripts like preinstall, install, and postinstall no longer run automatically. You approve them instead. The reason is blunt. Install scripts were the classic attack vector in npm supply-chain incidents: a malicious package could execute arbitrary code the moment you ran npm install on it. Closing that door by default was overdue.

In practice, here's what you'll see:

• Packages that legitimately compile native code (anything using node-gyp, like bcrypt or sqlite3) may pause and ask you to approve their build scripts.
• Git dependencies are blocked by default unless you enable them with an allow-git setting.
• Remote URL tarballs (direct HTTPS tarball references) are blocked unless explicitly allowed.

If you were on npm 11.16.0 or newer before the switch, you had already seen these as advisory warnings; the npm team rolled the change out in warning mode before defaults became blocking. Your terminal has probably been telling you about this for a while.

The failure mode is easy to recognize. The install appears to succeed, then the package crashes at runtime because its build step never ran. Check the npm output for the script-approval message, approve the package if you trust it, and reinstall. Nine times out of ten, that's the whole fix.

Common errors and how to fix them

EACCES permission errors on global installs. Almost always caused by a system-installed Node. Fix: move to a version manager, or change npm's global prefix to a user-owned directory (npm config set prefix ~/.npm-global and add it to your PATH). Don't use sudo as a band-aid.

"Command not found" after a global install. The global bin directory isn't on your PATH. Run npm bin -g (or npm root -g and look for the bin subfolder on newer npm versions) and add that directory to your PATH.

node-gyp build failures. This is what happens when you install node package code that ships C or C++ sources on a machine without build tools. Native compilation needs Python and a toolchain (Xcode Command Line Tools on macOS, build-essential on Debian/Ubuntu, Visual Studio Build Tools on Windows). Install the toolchain, then retry. With npm 12, also confirm the package's build script was approved.

Corrupted node_modules. It happens. Delete node_modules and package-lock.json, then run npm install fresh. Cheap to try, and it fixes a surprising number of phantom issues.

Slow installs on big projects. Run npm ci instead of npm install in CI environments; it's faster because it uses the lockfile directly and skips resolution work. Locally, a warm npm cache usually makes repeat installs quick enough.

npm, pnpm, yarn, bun: which should you use?

npm is the default and the safe choice; it ships with Node and every tutorial assumes it. But alternatives are worth knowing, and whichever tool you use to install node package modules, the same package.json carries over, so switching later is painless.

pnpm is the one I'd genuinely recommend trying. Its content-addressed store means packages are stored once on disk and hard-linked into each project, which dramatically cuts disk usage and install times on multi-project machines. Its strict dependency resolution also prevents you from importing packages you never declared, which is good hygiene. Yarn is a fine alternative but has lost much of its early momentum. Bun is the interesting newcomer: a full JavaScript runtime with a built-in, very fast package installer, and you can even run bun install inside npm-based projects to speed things up. There's an active community experimenting with running Node packages entirely without npm via Bun and CDN-based module delivery, though for real projects the maturity of npm's ecosystem still wins. For most readers: start with npm, switch to pnpm when install times or disk space start annoying you.

Deploying: your packages have to live on a server too

Installing packages locally is half the story. The moment your app goes live, every one of those dependencies has to be installed on the server as well, and that's where lockfile discipline and Node version pinning stop being academic. Put a .nvmrc in your repo and run npm ci at deploy time, and production gets the exact dependency tree you tested against.

None of that goes smoothly if your host locks the environment down. You need a server that lets you install node package dependencies at deploy time, pin Node versions, and run build scripts on demand. Shared platforms that block script execution tend to choke on packages that need node-gyp, which is why for Node work I'd pick a VPS or dedicated server every time. It's also why AvenaCloud builds its cloud hosting solutions around configurable VPS and dedicated servers with full root access: with root, npm 12's script policies, native toolchains, and custom Node versions are entirely yours to manage. If you're not sure what size server your workload needs, the support team can help you match it instead of guessing.

Your next step

If Node isn't installed yet, set up nvm (or nvm-windows) and grab the current LTS; that takes about two minutes and permanently eliminates the sudo-and-permission-error rabbit hole. Then run npm init -y in a scratch folder, install express, and open package.json to see how npm recorded it. Clone a real project afterward and run npm ci to feel what a lockfile buys you. Once those work, you've covered the full loop: init, install, run, deploy.

FAQ

How do I install Node and npm? Use a version manager: nvm on macOS/Linux, nvm-windows on Windows. npm ships bundled with Node, so one install covers both.

What is the command to install node modules? npm install installs everything listed in package.json into node_modules. You can also install node package tarballs directly from a URL or a local file with npm install <tarball>, which is handy for testing unreleased builds.

How do I install a specific version of a package? Append the version: npm install react@18.3.1, or a range such as npm install lodash@^4.17.21.

Why won't my package install under npm 12? Most often its install scripts were blocked by the new security defaults, or it's a git or remote-URL dependency that needs an explicit allow setting. Check npm's output for the script-approval prompt and add trusted packages to your project's allowlist.