What Is npm?
npm is the default package manager for Node.js and the world's largest software registry. It has two parts: a public registry hosting over two million open-source JavaScript packages, and a command-line tool that installs, updates, and manages those packages inside a project. When you run npm install, it downloads the libraries your code depends on, records them in package.json, and locks exact versions in package-lock.json so every environment builds identically.
- Type
- Default package manager bundled with Node.js
- Registry size
- Over 2 million packages, the largest software registry (npm Docs)
- Key files
- package.json declares dependencies; package-lock.json pins exact versions
- Common commands
- npm install, npm run, npm update, npm audit
- Security
- npm audit flags known vulnerabilities in dependencies (npm Docs)
What npm actually is #
npm stands for Node Package Manager, and it is the default tool for sharing and installing JavaScript code. It ships automatically when you install Node.js, so most developers get it without a separate download. Two things wear the npm name: the public registry, an online database of open-source packages anyone can publish to, and the CLI, the npm command you type in a terminal. Together they solve a simple problem: modern web projects lean on hundreds of small, reusable pieces of code, and copying those by hand would be error-prone. Instead you declare what you need, and npm fetches the right versions and their dependencies for you. Whether the team building your site uses React, a build tool, or a testing library, npm is almost certainly the plumbing pulling those pieces together. Any agency doing /services/web-app-development relies on it daily, and understanding it helps you read a project's dependencies and judge its health.
The registry versus the command line #
It helps to separate npm's two halves. The registry (registry.npmjs.org) is a massive public library hosting more than two million packages, from tiny one-line utilities to full frameworks. Publishing is open, which is why it grew so large and also why quality varies. The CLI is the program that talks to that registry: it reads your project's requirements, downloads matching packages into a node_modules folder, and wires everything together. You rarely browse the registry website directly; instead you name a package and let the CLI resolve it. This split matters for trust, because anyone can publish, so the package you install is only as safe as its author and maintainers. Reputable projects show frequent updates, many downloads, and active issue tracking. Before adding a dependency to a production site, a careful developer checks those signals, because every package becomes part of your codebase and, potentially, part of your /services/website-security surface. A tidy dependency list, kept small and current, is far easier to audit and defend than a sprawling one accumulated without scrutiny over the years.
How package.json describes a project #
At the root of nearly every Node or front-end project sits a file called package.json. It is a plain-text manifest that names the project, its version, its scripts, and, most importantly, its dependencies. Two lists appear: dependencies, packages your app needs to run, and devDependencies, tools needed only while building or testing, like bundlers and linters. Each entry pairs a package name with a version range. Because this file is small and human-readable, it travels with the code in version control instead of the bulky node_modules folder. When a new developer clones the project, running npm install reads package.json and reconstructs the full dependency tree locally. package.json also defines named scripts, so npm run build or npm run test triggers whatever commands the team standardized. Reading this one file tells you a lot about a project: its stack, its tooling, and how actively its dependencies are maintained across the codebase. Because it is committed to version control, package.json also acts as living documentation that any future developer can read to understand what the project relies on.
Why the lockfile matters #
package.json specifies version ranges, not exact versions, so two installs weeks apart could pull slightly different code. That is where package-lock.json comes in. Generated automatically, the lockfile records the exact version of every package and sub-dependency that was installed, down to a cryptographic hash. Committing it to version control means every teammate, every server, and every deployment builds from the identical dependency tree, eliminating the classic 'works on my machine' bug. For reproducible production deploys, developers often use npm ci instead of npm install, which installs strictly from the lockfile and fails if it disagrees with package.json. If your site suffers mysterious failures after an update, a mismatched or missing lockfile is a common culprit. Keeping it clean and committed is a small discipline that saves hours, and it is exactly the kind of thing a good /services/care-plans provider watches during routine maintenance so builds stay predictable over the long life of a site.
Installing and running packages #
A few commands cover most day-to-day npm work.
# install everything listed in package.json
npm install
# add a package and save it to dependencies
npm install axios
# add a dev-only tool
npm install --save-dev eslint
# run a named script from package.json
npm run build
# check for known vulnerabilities
npm audit
# reproducible install from the lockfile
npm ciSemantic versioning and version ranges #
npm packages follow semantic versioning, written as MAJOR.MINOR.PATCH, for example 4.18.2. The rules are a promise: patch releases fix bugs, minor releases add features without breaking existing code, and major releases may break compatibility. In package.json you often see a caret, like ^4.18.2, which tells npm to accept any compatible 4.x version but never jump to 5.0. A tilde, ~4.18.2, is stricter, allowing only patch updates. Understanding these symbols explains why an npm install months later can quietly upgrade minor versions while the lockfile holds the exact ones you tested. When maintainers honor semver, updates are low-risk; when they do not, minor bumps can still break a build. This is why the lockfile and testing matter. For business owners, the takeaway is simple: dependency updates are routine but not free, and they deserve the same care as any other change to a live site before deployment. A developer who understands these version symbols can upgrade deliberately, testing changes in a safe environment first rather than letting an update surprise a live site.
Security and supply-chain risk #
Because npm packages can depend on other packages, a single install may pull in dozens of authors' code. That convenience carries risk: a vulnerability or malicious update in any dependency becomes your problem too. npm addresses part of this with npm audit, which compares your installed versions against a database of known vulnerabilities and suggests fixes. Running it regularly, and reviewing what a new package brings with it, is basic hygiene. High-profile incidents have shown that even popular packages can be compromised, so cautious teams pin versions, limit dependencies, and enable automated alerts. None of this makes npm unsafe to use, because it powers most of the modern web, but it means dependencies are part of your attack surface. Treating them as such is central to good /services/website-security practice, and it is one reason routine maintenance and monitoring matter as much for a Node app as patching a server or updating a WordPress plugin.
npm versus Yarn and pnpm #
npm is the default, but it is not the only package manager. Yarn arrived to improve speed and reliability, and pnpm became popular for saving disk space by sharing a single copy of each package across projects. All three read the same package.json and pull from the same public registry, so switching is usually possible, though each keeps its own lockfile format. For most small-business projects the choice barely matters; npm is universal, well-documented, and perfectly capable. Teams pick alternatives mainly for large monorepos or strict performance needs. If you inherit a project, check which lockfile exists, package-lock.json for npm, yarn.lock for Yarn, pnpm-lock.yaml for pnpm, and stick with it to avoid conflicts. The practical advice: do not agonize over the tool. Consistency within a project matters far more than which manager you chose, and any competent developer handling your /services/web-app-development can work comfortably with all three. If you are simply maintaining an existing site, the safest course is to keep using whatever lockfile the project already has, since mixing managers in one repository invites subtle dependency conflicts.
What npm means for your website #
For a small-business owner, npm rarely demands your direct attention, yet it quietly shapes the health of any custom site or app you commission. The dependencies listed in package.json are, in effect, a bill of materials for your website: each one is code someone else wrote that now runs on your behalf. A project with a lean, well-chosen, current set of packages is easier to maintain, faster to secure, and cheaper to update than one carrying dozens of outdated or abandoned libraries. When you commission /services/web-app-development, it is fair to ask how many dependencies a project pulls in, whether they are actively maintained, and how updates will be handled over time. You do not need to read the code, but you can expect a developer to keep npm packages patched, run npm audit periodically, and avoid piling on unnecessary libraries. Treated with that discipline, npm is a quiet asset; neglected, it slowly becomes technical debt and a genuine security liability sitting inside an otherwise healthy and well-designed site.
FAQ
Is npm free to use?
Yes. The npm CLI and the public registry are free, and installing or publishing public packages costs nothing. npm also offers paid plans for private packages and organization features, but the vast majority of open-source work, including most small-business websites and apps, uses the free public tier without ever paying anything.
Do I need to know npm to run a website?
Not usually. If your site is built on WordPress or a hosted platform like Shopify, npm runs behind the scenes, if at all. It matters most for custom JavaScript apps and modern front-end builds. Your developer handles it; you mainly benefit from knowing it exists when reading a project or a quote.
What is the difference between npm and Node.js?
Node.js is the runtime that executes JavaScript outside a browser, on a server or your machine. npm is the package manager that ships with Node.js for installing libraries. You install Node.js first; npm comes along automatically. One runs your code, the other manages the reusable code your project depends on.
What is node_modules?
node_modules is the folder where npm places every downloaded package for a project. It can grow large, thousands of files, because dependencies have their own dependencies. It is never committed to version control; instead package.json and the lockfile let anyone rebuild it with a single npm install. Deleting and reinstalling it is a common fix.
What does npm install actually do?
It reads package.json, resolves every dependency and sub-dependency, downloads them from the registry into node_modules, and writes or updates package-lock.json with the exact versions installed. Run without a package name it installs everything the project needs; with a name it adds that package and records it. It is the command that assembles a project's code.
Is it safe to use npm packages on a business site?
Generally yes, since npm underpins most of the modern web, but each package is third-party code, so vet what you add. Prefer well-maintained, widely used packages, run npm audit for known vulnerabilities, and keep dependencies updated through routine maintenance. Treating dependencies as part of your security surface, not free magic, keeps the risk manageable.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?