Understanding
packages
Almost no software is written from scratch. Knowing what you install, and what gets installed with it, is the difference between using other people’s work and depending on code nobody has looked at.
Scroll, click, or use the arrow keys to move through.Scroll, or use the arrows and dots to move through.
A package is code someone else wrote that you install and use.
Reading a spreadsheet, drawing a chart, parsing a PDF, handling timezones: all of it is already solved, tested across thousands of companies, and available in one line. Most software is assembled from parts like these rather than written from nothing.
The question is not whether to use other people’s code, but which packages and how many.
A package manager installs the package and everything it depends on.
npm for JavaScript, pip for Python, and an equivalent for every other language. You name what you want, and it downloads that package from a public registry and installs it.
It also installs whatever that package depends on, and whatever those depend on, all the way down. Those indirect dependencies are the part most teams never look at.
Ten packages typically install several hundred.
This is normal for a project of any realistic size. It also means most of the code running in your product was written by people your team cannot name.
Packages change, and that is where most surprises come from.
Every package has versions, and new ones ship constantly: fixes, new features, and occasionally a change that breaks something you relied on. A project that asks for the latest version of everything can behave differently today than it did yesterday without anyone having touched it.
A lockfile records the exact version of every package, direct and indirect, that the project is known to work with. Everyone installs the same set, and upgrades happen when someone decides to make them.
A project should install the same way every time.
The leverage is real, and so is the dependence.
A widely used package saves years of work. It is also code your team did not write, has not read, and did not review, running with the same access as your own code.
Maintainers stop maintaining. Ownership changes hands. Occasionally a package is compromised deliberately, and everyone who installed it that week is affected.
None of this is an argument against using packages. It is an argument for choosing them deliberately.
Fewer, larger, better maintained.
- When was it last updated, and by how many people?
- How many other projects depend on it?
- What is the license, and does it permit what you intend to do?
- If it were abandoned tomorrow, what would happen to us?
None of these require reading the code. They are supplier questions, and they catch most of what goes wrong.
An AI will add packages without being asked.
Request a feature and the result may include several new dependencies, chosen in a second and usually chosen sensibly. The habit worth building is to check what was added, why it was added, and whether you would have chosen it.
This belongs with the verification habits from lesson eleven rather than in a separate review nobody runs.
Review what was installed, not only what was built.
Use other people’s code, and know what you are using.
Take the leverage. Keep the list of direct dependencies short. Pin the versions. Ask the supplier questions before adding one, and check what was installed on your behalf. Most problems come from dependencies nobody chose deliberately.