Dependency Doctor

Generic advice about outdated packages is easy to generate and hard to trust. I wanted to see how AI can fit into an engineering workflow without being asked to invent facts.

• Next.js and TypeScript app with a package.json parser and input validation.
• Resolves each requested version range against live npm registry metadata.
• Looks up known vulnerabilities for the resolved versions through the OSV database.
• Detects peer-dependency conflicts using registry data and semver range intersection.
• Sends the collected facts to an LLM, which returns a structured, prioritised report.

1. package.json

   →

2. Parse + validate

   Zod

   →

3. npm registry

   versions, peers

   →

4. OSV

   vulnerabilities

   →

5. LLM

   structured JSON

   →

6. Report

Facts first, model second

Versions, deprecations, vulnerabilities and peer conflicts are computed deterministically. The model never decides what is true; it only explains and ranks what the pipeline already found.

Structured output, validated twice

The model is asked for strict JSON-schema output, and the response is parsed again with Zod. A malformed answer fails loudly instead of rendering something misleading.

Swappable provider

Analysis sits behind a small interface, so the AI provider and the package registry are replaceable without touching the rest of the pipeline.

Bounded external calls

Registry and OSV requests run with timeouts and limited concurrency, so one slow package cannot hang the whole analysis.

• Next.js
• React
• TypeScript
• Node.js
• Zod
• semver
• OSV API
• LLM APIs
• Docker

Live at dependencydoctor.in, a working example of AI integrated into a developer workflow as one step in a pipeline, not the whole product.