Dependency Audit
Decides whether a library earns its place, or whether twenty lines of your own would do.
When to reach for it
The moment an agent proposes installing a package — especially for something that sounds like it should be small, like formatting a date or generating an id.
What changes
- Before installing, the agent states the one thing the package is needed for, which is usually a fraction of what it ships.
- You see the real cost: how much it pulls in, how big it is, when it last shipped, and how many of your files would import it.
- For small utilities the agent writes the hand-rolled version and puts it next to the install command, so the comparison is concrete rather than theoretical.
- What you already have gets checked first, so you stop adding a second library that does what an installed one already does.
- Anything unmaintained, or doing vastly more than the task needs, gets flagged before it reaches the lockfile.
Pairs with
- Rewrite or RepairForces an honest answer to 'fix it or start over', costed in evidence rather than taste.
- Spike Then DecideBuys certainty about an unknown approach with a throwaway experiment on a fixed budget.
- Assumption CheckMakes the agent state what it is assuming — and verify it — before it writes a line.
Dependency Audit
Run this before adding any package. It takes a minute, and it is the cheapest decision in the project to get right.
1. Write the sentence
"We need this to do X." X is the specific thing this task requires, not the package's tagline. "To turn an ISO date string into a date object" rather than "for date handling".
2. Check what is already here
Read the manifest and the lockfile. Two things happen more often than you would expect: the capability is already present in something you have installed, or the platform now provides it natively. Check both before going further.
3. Look at what it costs
For the candidate, find out:
- How many further packages it drags in behind it.
- Its installed size, and whether it ships to the browser.
- When it last released, and whether its open issues get replies.
- How many files in this project would import it.
A package used in one file is easy to remove later. A package used in forty is a decision you are making on behalf of the whole project.
4. Write the alternative, do not describe it
If the need is small, write the version you would write by hand and count the lines. Then compare honestly:
- Under about thirty lines with no subtle edge cases: write it.
- Correctness is genuinely hard — time zones, parsing, cryptography, unicode, money rounding: take the library.
- In between: prefer whichever one you could delete more easily.
5. Present both and let the user pick
Show the install and the hand-written version side by side, with one line of recommendation and the reason for it.
Rules
- Do not install a general-purpose library to use one function from it.
- Do not write your own cryptography, authentication, date arithmetic, or text encoding. "It is only twenty lines" is how those go wrong.
- Do not slip an install into the same change as the feature without saying so. New dependencies should be visible, never incidental.
- Do not judge a package by popularity alone. A widely used package that has not shipped in three years is still a package that has not shipped in three years.