What is a package manager (npm) — and where the node_modules folder comes from

You type one command — npm install — and suddenly your project has a node_modules folder that weighs more than all your own code. Hundreds of megabytes, thousands of files you never wrote. Here's the trick: you just hired thousands of other programmers for free. Let's unpack what a package manager is, and why it's both your superpower and a place worth watching.

A package is someone else's ready-made code

Almost any routine task has already been solved by someone and published as a package — a bundled piece of code you can download and plug in. Need a calendar? Date handling? Nice charts? Don't write it from scratch — grab the ready-made one.

A package manager is the program that downloads all of this and lays it out for you. In the JavaScript world it's called npm (Python has pip, other languages their own). You say "install package X," and it finds it in a shared registry, downloads it, and drops it into your project.

It's part of the same ecosystem as an SDK and frameworks: ready-made bricks so you assemble instead of quarrying stone by hand.

Where all those files in node_modules come from

Here's the main surprise. You asked for one package — and two hundred arrived. Why?

Because a package has dependencies — other packages it needs itself. And those have their own dependencies. And so on, all the way down. Installing one calendar, you pull in the whole tree it leans on.

node_modules is that entire tree, unpacked onto disk. Hence the joke that it's the heaviest object in the universe. You don't commit it to your repo: a list of packages in the package.json file is enough, and anyone can rebuild node_modules from scratch with one npm install.

Why it's a superpower — and where the risk is

The superpower is obvious: what would take weeks plugs in within a minute. No vibe-coder writes from scratch what already works reliably for thousands of people.

But other people's code in your project has a cost worth remembering:

• You're trusting strangers. Every package is code that will run on your machine. A known attack: someone slips malware into a popular package, and it spreads across thousands of projects.
• More packages means more weight and holes. Each dependency is a potential vulnerability. Fewer is healthier.
• Packages age. An abandoned package eventually breaks on newer versions.

How to use it wisely

• Install only what you need. Don't pull a whole library for one function you could write in three lines.
• Check the package's liveness. Recent updates and lots of downloads signal that someone's maintaining it.
• Check the name. A typo in the name (reakt instead of react) is a known way to sneak you a malicious twin. It's a close cousin of keeping your keys secret: basic hygiene that saves headaches.
• node_modules goes in .gitignore. Commit package.json, not gigabytes of dependencies.

Why commit package.json instead of node_modules?

package.json is a short list: which packages and which versions you need. From it, anyone (your code editor and your deploy server alike) rebuilds an identical node_modules with npm install. There's no reason to lug the gigabytes around.

npm, pip, yarn — what's the difference?

They're different package managers for different languages and tastes: npm and yarn for JavaScript, pip for Python. The idea is the same: install other people's code with one command. The syntax and small details differ.

Can I delete node_modules?

Yes, safely. Delete it to free up space; need it again — npm install rebuilds the folder from package.json. It's a temporary cache, not part of your project.