What Package Management Is — What npm install Installs, and Where

This article covers package management.

It is the mechanism that fetches an external library by name with a single line such as npm install and puts it in a fixed place.

You type only the one line on the left, and the two things on the right are what get added.

All that grows is the node_modules folder and one line in package.json; the app.js you wrote yourself does not change by a single character.

What a package is — an external library you fetch by name

An external library bundled into a form you can fetch by name is a package, and the number that identifies its contents at that point is the version.

When you want to display dates in a readable form in the booking app my-app, you can write that processing yourself, but it is also distributed as a package.

On the left, all the lines you wrote are yours; on the right, you just call what you fetched in one line.

What you specify when fetching is only the name at the top.

The "names of other packages it needs" at the bottom are what increase the number of folders later.

A package is an external library you can fetch by name

A package is a program someone else wrote, given a name and put into a form that can be distributed.

Specifying the name brings its contents onto your computer, and the version is the number that tells revisions apart within the same name.

What appears inside my-app when you type npm install react

The thing that fetches by name is the package manager — a program that fetches packages and puts them in a fixed place — and the JavaScript one is npm.

Each is a single line in the terminal, and both assume you are typing inside my-app.

# Move into the my-app folder first
cd my-app

# Fetch one package by the name react
npm install react

# Fetch all the names listed in the manifest file at once
npm install

Fetched packages go into node_modules — the folder npm creates inside my-app to hold the packages it fetched.

The files you write and the folder npm creates sit separately inside the same my-app.

Even for the same one line, the result changes depending on how you type it and on whether the name is misspelled.

As in the third row, if a mistyped name does not exist in the registry, nothing is installed.

If a mistyped name happens to exist, something else gets installed, so copy names from the official page.

The packages react needs, and the packages those need in turn, all come along.

Not having to look up that whole set and fetch it one by one is the reason to use a package manager.

Fetching one package does not mean only one folder is created in node_modules.

The registry is another computer on the far side of the Internet.

The only place fetched packages are put is node_modules inside the my-app folder.

The app.js you wrote calls the packages in there and uses them.

What you fetch goes into node_modules

What you fetch goes into the node_modules folder created inside my-app.

The app.js you wrote does not change, and there are more folders than the number you named because what the fetched package needs comes along too.

package.json — the manifest file listing the names of the packages you fetched

The contents of node_modules are created by npm, and you do not edit them yourself.

The only thing you manage is the single file that lists the names you fetched.

That is the manifest file — package.json in JavaScript — which records the names of the packages the app needs in order to run, and each name listed there is called a dependency, a package your own code needs in order to run.

{
  "name": "my-app",
  "dependencies": {
    "react": "^19.0.0",
    "express": "^5.1.0"
  }
}

The two entries listed under dependencies are this my-app's dependencies.

The right-hand side specifies the version to fetch; the numbers are for this example, and in practice whatever was current when you fetched goes in.

The leading ^ marks that "newer versions compatible with the number written here are also allowed."

Besides dependencies, package.json records other things too.

What npm install reads is the dependencies part in the middle.

One and the same thing has three names, depending on where you look at it from.

Because the manifest file exists, you do not have to hand node_modules to anyone.

You hand over app.js and package.json, and the other person types npm install once.

npm reads only the dependencies in package.json, fetches the names listed there from the registry, and rebuilds node_modules.

There is no need to hand over node_modules itself.

With the list of names alone, the contents can be rebuilt

package.json is the file that lists the names of the packages this my-app needs in order to run.

npm install reads this file and fetches all the names at once, so node_modules can be rebuilt at any time and never has to be handed to anyone.

The same in Python — pip, requirements.txt, and virtual environments that separate where packages go

So far we have looked at this with JavaScript names.

In Python the names differ, but what is being done is the same.

pip is what fetches, and requirements.txt is the manifest file that lists the names.

Since the roles are the same, learning one lets you read the other the same way.

The one thing that differs is where packages go: without a virtual environment, pip installs them system-wide.

What you create to avoid this is a virtual environment — a mechanism that creates a folder holding the packages for that app alone.

When the folders are separate per app, different versions of the same name can sit side by side without colliding.

Setup instructions have you create a virtual environment first in order to make that separation.

The three roles are the same across languages

Every language has a program that fetches, a manifest file that lists the names, and a place where what arrives is kept.

In JavaScript that is npm, package.json, and node_modules; in Python it is pip and requirements.txt, and in Python alone the packages go system-wide unless you create a virtual environment.