npm & Yarn Cheat Sheet
Covers installing and managing packages, package.json scripts, semantic versioning ranges, lockfiles, and key npm versus Yarn command differences.
Installing & Managing Packages
Core install commands for npm and Yarn.
# npmnpm install # install all deps from package.jsonnpm install lodash # add a dependencynpm install -D typescript # add a devDependencynpm uninstall lodashnpm update # update within each package's semver rangenpm ci # clean install from lockfile (CI-safe)# yarn (classic v1)yarn installyarn add lodashyarn add -D typescriptyarn remove lodashyarn upgrade
package.json Scripts
Defining and running custom scripts.
npm run dev # explicit "run" needed for custom script namesnpm start # shorthand for the "start" scriptnpm test # shorthand for the "test" scriptyarn dev # yarn omits "run" for any script nameyarn build
Semver Ranges & Version Bumps
Dependency version ranges and release tagging.
// package.json dependency ranges"lodash": "4.17.21" // exact version"lodash": "^4.17.21" // compatible with 4.x.x (minor/patch updates)"lodash": "~4.17.21" // patch-level updates only (4.17.x)"lodash": "*" // any version (avoid in production)
Key Commands & npm vs Yarn
Lockfiles and notable command differences.
- package-lock.json / yarn.lock- locks exact resolved versions for reproducible installs across machines
- npm ci- faster, strict install used in CI; fails if the lockfile is out of sync with package.json
- npx <pkg>- runs a package's binary without installing it globally
- npm link- symlinks a local package for local development and testing
- workspaces- both npm (7+) and Yarn support monorepo workspaces declared via a workspaces field in package.json
- yarn dlx <pkg>- Yarn Berry's equivalent of npx for one-off binary execution
Forcing Transitive Dependency Versions
Overriding a nested dependency's version without waiting on its parent to bump.
// npm (package.json) — npm 8.3+{ "overrides": { "semver": "^7.5.4" }}// yarn classic (package.json){ "resolutions": { "**/semver": "^7.5.4" }}// yarn berry equivalent: yarn.config.cjs or `yarn set resolution`
Publishing a Package
Controlling what ships and verifying it before it's public.
npm pack --dry-run # preview the exact tarball contentsnpm publish --access public # scoped packages default to privatenpm publish --tag next # publish under a dist-tag, not "latest"npm version patch # bump version + create a git tagnpm deprecate pkg@"<2.0.0" "use v2, see MIGRATION.md"
Controlling the Published Tarball
The files and exports fields that shape what consumers actually see.
{ "files": ["dist", "README.md"], "main": "dist/index.cjs", "module": "dist/index.mjs", "types": "dist/index.d.ts", "exports": { ".": { "import": "./dist/index.mjs", "require": "./dist/index.cjs", "types": "./dist/index.d.ts" }, "./package.json": "./package.json" }, "sideEffects": false}
Pinning the Package Manager with Corepack
Guaranteeing every contributor and CI runner uses the same npm/Yarn version.
# package.json# "packageManager": "[email protected]"corepack enable # activates the shim for npm/yarn/pnpmcorepack prepare [email protected] --activate# .npmrc (project-level)engine-strict=truesave-exact=true
Advanced Concepts
Terms that matter once you're publishing or running a monorepo.
- peerDependencies- declares a package the consumer must provide (e.g. react); not auto-installed by npm 7+, just validated
- npm audit / audit fix- scans the dependency tree against known vulnerability advisories and can auto-bump affected packages
- engines field- declares required Node/npm versions; combine with engine-strict=true in .npmrc to hard-fail on mismatch
- Yarn Plug'n'Play (PnP)- Yarn Berry mode that skips node_modules entirely, resolving imports from a single .pnp.cjs map for faster installs
- npm dedupe- flattens the dependency tree to remove redundant duplicate installs of the same version
- workspace protocol (workspace:*)- Yarn/pnpm syntax that links a monorepo-local package by path instead of resolving it from the registry
- npm ls --all- prints the full resolved dependency tree, useful for tracking down which package pulled in a bad transitive version
Commit your lockfile and always run npm ci (not npm install) in CI: it enforces exact reproducibility and fails fast if package.json and the lockfile have drifted apart, instead of silently resolving new versions.