define dependency-package --plain-english
Dependency / Package
TLDR:When we covered open source, I told you your favorite apps aren't built from scratch.
When we covered open source, I told you your favorite apps aren't built from scratch. They're stitched together from free pieces other people already made. Those pieces have a name, and your project is leaning on dozens of them right this second.
A dependency is exactly that: a pre-built chunk of someone else's code your project uses instead of writing its own. When it's bundled up so it's easy to grab and drop in, it's called a package. Your project "depends on" it, which is where the name comes from.
Store-bought pie crust. You're making a pie. You could mill your own flour and build the crust from scratch, or you buy the crust (which a company already perfected) and spend your energy on the filling that's actually yours. The store-bought crust is a dependency. Your pie depends on it. You didn't make it. Your dessert leans on it. And nobody gives you grief for not having grown the wheat.
Why every project does this, and it's sanity, not laziness. The boring, hard, already-solved problems, like handling dates, processing payments, parsing a file, drawing a calendar, somebody already built, tested, and hardened over years. That's open source doing its job. Rewriting it yourself would be slower and worse. So you grab the package and pour your effort into the part that's genuinely yours.
Where you'll actually see it: a file often called package.json is literally the shopping list, every borrowed piece your project needs, by name and version. "Install the dependencies," or npm install, just means go fetch everything on the list and stock the pantry. An agent runs this constantly the moment it sets up a project.
Two honest catches, because this is also where things quietly go wrong:
Dependencies have dependencies. Your pie crust was made with someone else's flour, which used someone else's fertilizer. A small project can silently pull in hundreds of packages, most of which you've never heard of. That tower mostly holds, until one brick deep down breaks or goes bad on purpose. (Remember the bots that scan public code for leaked keys? A poisoned package somebody slipped into the supply chain is a real cousin of that, and it's worth knowing the door exists.)
Versions matter. The crust you bought last year and the one this year might be slightly different recipes. Pin which version you're using, or a routine "update" can quietly change the taste of your whole pie.
Why a non-coder should care: it reframes what "building" even is. You're not carving every piece from raw wood. You're choosing good pre-made parts and assembling them well. So when your agent says "I'll add a package for that," it isn't cutting a corner. It's the entire modern way software gets built.
A dependency is store-bought pie crust. You didn't make it, your project leans on it, and that's not cheating. It's why you get to spend your time on the filling.