npm cheat sheet

Status: đźź© COMPLETE Last updated: 2026-06-21 Plain-English tagline: Daily-use npm commands grouped by intent. For the why, read npm & package managers.


Setup / sanity

node --version                           # which Node am I on?
npm --version                            # which npm?
npm config list                          # what config is active?
npm config get registry                  # which registry am I pulling from?

Installing packages

npm install                              # install everything in package.json
npm install <package>                    # add + install a runtime dep
npm install -D <package>                 # add + install a DEV dep (testing, types, etc.)
npm install -g <package>                 # install globally (CLI tools)
npm install <package>@<version>          # pin a specific version
npm install <package>@latest             # update to latest
npm uninstall <package>                  # remove a dep
npm update                               # update deps within their version ranges

Shorthand: npm i = npm install. npm i -D works too.


What’s installed?

npm list                                 # what's actually installed (top-level)
npm list --depth=0                       # explicit top-level only
npm list -g --depth=0                    # what global tools do I have?
npm outdated                             # what's behind its latest version?
npm view <package>                       # info about a package (versions, deps, repo)
npm view <package> versions              # all available versions

Running scripts (Next.js project)

npm run dev                              # start the Next.js dev server
npm run build                            # production build (RUN BEFORE EVERY PUSH)
npm run start                            # serve the production build locally
npm run lint                             # run ESLint
npm run type-check                       # run tsc --noEmit if defined
npm test                                 # run tests (no `run` needed for `test`)

Custom scripts live in package.json under "scripts": {...}. npm run with no args lists them all.


Cleaning up

rm -rf node_modules package-lock.json    # nuclear reset (PowerShell: Remove-Item -Recurse -Force)
npm install                              # rebuild from scratch
npm cache clean --force                  # rarely needed; flush npm's cache
npm prune                                # remove deps not listed in package.json

On Windows PowerShell, the nuke is:

Remove-Item -Recurse -Force node_modules, package-lock.json
npm install

Quick exploration / one-off tools

npx <package>                            # run a package without installing
npx create-next-app@latest               # create a new Next.js project
npx shadcn@latest add button             # add a shadcn/ui component
npx eslint .                             # run eslint without installing

npx downloads the package on demand, runs it once, and (optionally) caches it. Perfect for tools you use rarely.


Publishing (rarely needed for app dev)

npm login                                # log into npmjs.com
npm whoami                               # confirm you're logged in
npm publish                              # publish the current folder as a package
npm version patch                        # bump version (1.0.0 → 1.0.1)
npm version minor                        # bump (1.0.0 → 1.1.0)
npm version major                        # bump (1.0.0 → 2.0.0)

Configuration / .npmrc

npm config get prefix                    # where global packages install
npm config set prefix "C:\Users\georg\AppData\Roaming\npm"   # Windows default
npm config set save-exact true           # always pin exact versions on install

.npmrc files live at ~/.npmrc (global) and in any project (local override).


Common workflows

Fresh project setup

npm install                              # install everything package.json declares
npm run dev                              # start the dev server
# (build before pushing)
npm run build

Adding a new dependency

npm install @supabase/supabase-js        # add to package.json + node_modules
# (now you can `import { createClient } from "@supabase/supabase-js"`)

Bumping a misbehaving dep

npm outdated                             # see what's behind
npm install <package>@latest             # update one specifically
# (test it)
git diff package.json package-lock.json  # see what changed

”Module not found” or “weird build error”

Standard reset:

# Bash / macOS / Linux
rm -rf node_modules package-lock.json
npm install
npm run build
 
# PowerShell / Windows
Remove-Item -Recurse -Force node_modules, package-lock.json
npm install
npm run build

This fixes most mysterious npm problems.


Common gotchas

  • package-lock.json is sacred — commit it. It pins exact versions for reproducible builds. Without it, two installs can get different code.
  • Never edit node_modules/ directly. It gets blown away on every npm install. If you need to patch a dep, use the patch-package library.
  • -g (global) on Windows can need elevated permissions. Either run as admin or change the prefix to a user-owned folder.
  • npm install after git pull is rarely a habit but often needed. If teammates added deps, your local node_modules is missing them. Symptoms: “module not found” on imports that exist in the code.
  • devDependencies vs dependencies matters in production. npm install --omit=dev skips dev deps. Vercel does this — if your build needs a dep, put it in dependencies.
  • Mixed package managers cause chaos. If a project uses npm, don’t run yarn or pnpm in it. The lockfiles conflict and node_modules ends up inconsistent.
  • npm audit can be noisy. It flags vulnerabilities in transitive deps that may or may not be exploitable for your use case. Triage, don’t auto-fix.
  • Cache issues are rare in modern npm. Don’t reach for npm cache clean --force as a first move — the nuclear reset above is more reliable.
  • PowerShell vs Bash command differences matter. rm -rf is Bash; PowerShell needs Remove-Item -Recurse -Force. Don’t blindly paste from tutorials.
  • npx runs the LATEST version each time unless you pin (npx package@1.2.3). Surprising when behavior changes between runs.

See also


Sources