You can do this, too. Steps that I took:
1. Find all unused package.json dependencies and remove them.
2. (If monorepo) De-duplicate any dependencies where you see multiple direct versions.
3. Calculate the largest contributors to our transitive lockfile closure from our direct dependencies.
4. Using 3's data, find low risk, high impact candidates that we can upgrade through minors/patches to reduce our transitive lockfile closure.
5. Using 3's data, find dependencies with trivial usage that we can inline.
6. Take a look at e18e\.dev to see if you can eke out any extra removals/replacements.
The above are summaries of the actual prompts I gave to GPT 5.5 (xhigh) in OpenCode to get you started. I ran these agents in the background while I was doing mainline work. Really good ROI. My bet is that if you did this in your repo and gave it real attention, you could end up with much larger reductions.
ALT :quality-intensifies: For those keeping score, removals in vercel/<repo> in this thread:
-34 direct package.json deps
-5,183 lines of pnpm-lock.yaml (-6.5%)
-504 package entries (-7.6%)
- :star: This is (net) 504 fewer points of pwn-ability for <repo>
-17,332 files of node_modules (estimated)
-2,469,373 lines of node_modules (estimated)
This makes <repo> more secure, faster, and easier to work with.
I have to head back to Turborepoland now, but let it be known:
- This took ~4 hours of my attention.
- There are many, many, many more candidates in <repo> (and beyond!) that could get this treatment. :delete-this: