Dependency Review

The Problem

Every dependency is a liability. Teams install packages for trivial functionality (left-pad, is-odd), adding kilobytes to bundles and attack surface to the supply chain. Abandoned packages with no updates in 2 years sit in production. Licenses incompatible with commercial use lurk in transitive dependencies. A single compromised package can inject malicious code into your build — and you would never know because nobody audits what npm install actually pulls in.

The Prompt

Review the following dependency list. Act as a supply chain security analyst evaluating each package for risk, necessity, and alternatives.

PACKAGE MANAGER: [npm / pnpm / yarn / pip / cargo]
PROJECT TYPE: [e.g., React SPA, Node.js API, Astro static site]

DEPENDENCY FILE:
[paste package.json, requirements.txt, or Cargo.toml]

Evaluate each dependency across these dimensions:

1. **Necessity**
   - Could this be replaced with native language/platform features?
   - Is the package used for a single function that could be hand-written in 10 lines?
   - Is it a dev dependency incorrectly listed as production?

2. **Health**
   - Last publish date and release frequency
   - Number of maintainers (bus factor)
   - Open issues and PR backlog
   - Downloads per week trend (growing, stable, declining?)

3. **Bundle Impact**
   - Minified + gzipped size
   - Does the package support tree-shaking (ESM exports)?
   - Are lighter alternatives available with the same functionality?

4. **Security**
   - Known CVEs in current or recent versions
   - Does the package have postinstall scripts?
   - How deep is the transitive dependency tree?
   - Has the package changed ownership recently?

5. **License Compliance**
   - Is the license compatible with commercial use (MIT, Apache-2.0, BSD)?
   - Are there any copyleft licenses (GPL, AGPL) in the dependency tree?
   - Are license obligations documented?

6. **Version Pinning**
   - Are versions pinned or using ranges (^, ~)?
   - Is there a lock file committed?
   - Are there conflicting version requirements?

Output a dependency health report:
| Package | Size | Last Update | License | Risk | Action |

Example Output

## Dependency Review: 12 packages analyzed

| Package | Size (gzip) | Last Update | License | Risk | Action |
|---------|-------------|-------------|---------|------|--------|
| lodash | 71.5 KB | 2024-02 | MIT | medium | Replace with lodash-es or native |
| moment | 67.9 KB | 2022-09 | MIT | high | Replace with date-fns or dayjs |
| axios | 13.7 KB | 2024-11 | MIT | low | Consider native fetch |
| uuid | 1.2 KB | 2024-08 | MIT | low | Keep or use crypto.randomUUID() |
| is-even | 0.1 KB | 2018-03 | MIT | high | Remove: n % 2 === 0 |
| colors | 6.2 KB | 2022-01 | MIT* | critical | Remove: maintainer sabotaged v1.4.1 |

### Critical: Supply Chain Risk — colors@1.4.1
The maintainer intentionally added an infinite loop in v1.4.1 as a protest.
Action: Remove immediately or pin to 1.4.0. Consider chalk as alternative.

### High: Abandoned Package — moment
No updates in 2+ years. Maintainers recommend alternatives. 67.9 KB gzipped.
Action: Migrate to date-fns (tree-shakeable, 12 KB for common operations).

When to Use

Run this at project kickoff, during quarterly dependency audits, or when bundle size becomes a concern. Essential before any security audit and when inheriting a project with an unfamiliar package.json. Use it to build a habit of questioning every npm install instead of blindly adding packages.

Pro Tips

• Check transitive dependencies too — run npm ls --all or pnpm ls --depth 5 and include the output for a complete picture.
• Ask for native replacements — follow up with “For each package marked ‘replace’, show me the native JS/Node.js code that replaces it.”
• Automate the audit — set up npm audit in CI and Dependabot/Renovate for automated vulnerability alerts.