Depscan

Point it at a local project folder. It reads package.json, greps your source files for where each dependency is actually imported, then uses Ollama to classify each one as actively used, used indirectly (build tools, type packages, CLIs invoked via scripts, etc), or possibly unused — with a one-line explanation of what the package does. Scans run locally; classification can use local Ollama or Ollama Cloud.

Preview

Prerequisites

• Bun installed
• Local mode: Ollama installed and running (ollama serve)
• Cloud mode: an Ollama API key
• A model available in the selected environment, e.g. llama3.1 locally or gpt-oss:120b in the cloud

Setup

bun install
bun run start

Then open http://localhost:3001 and enter the absolute path to any local project folder that has a package.json (e.g. /Users/you/code/my-app).

For auto-restart on file changes during development:

bun run dev

Config (optional)

• PORT — server port (default 3001)
• OLLAMA_ENV — Ollama environment: local (default) or cloud
• OLLAMA_URL — Ollama API base URL (default http://localhost:11434)
• OLLAMA_MODEL — model name to use (default llama3.1)
• OLLAMA_API_KEY — optional Ollama API key for cloud access

To use Ollama Cloud, set OLLAMA_ENV=cloud, provide an OLLAMA_API_KEY, and choose a cloud model such as gpt-oss:120b for OLLAMA_MODEL.

How it works

1. Scan (POST /api/scan) — fast, no AI involved. Walks the project's source files (.js .jsx .ts .tsx .mjs .cjs .vue .svelte, skipping node_modules, .git, dist, etc), and for every dependency in package.json checks whether it's imported/required anywhere, recording up to 5 example match locations.
2. Classify (POST /api/classify, one call per dependency) — sends the package name, version, dependency type, and example import lines to Ollama, which returns a verdict + short explanation. The frontend fires these with limited concurrency so rows fill in progressively instead of blocking on the whole project.
3. Click any row to expand it and see the full explanation plus the exact file:line matches that were found.

Notes & limits

• The import scanner is regex-based (looks for the package name inside quoted import/require strings) — it won't catch dynamic imports built from variables, and it doesn't resolve monorepo workspace packages.
• Verdicts are heuristic judgments from a local LLM, not ground truth — treat "possibly unused" as "worth checking," not "safe to delete."

Next steps to extend it

• Add a "remove & verify" flow that runs your test suite after uninstalling a flagged package.
• Cross-check flagged packages against package.json scripts (e.g. a dep invoked only via an npm script wouldn't show up as a source import).
• Cache classifications keyed by name+version so re-scanning is instant.
• Support monorepos by scanning multiple package.json files at once.