I built an open-source dependency intelligence platform in TypeScript — here’s how it works

Most teams find out their dependencies are risky after something breaks. A maintainer disappears, a vulnerability sits unpatched for months, or a single package with one contributor becomes a hidden outage waiting to happen. I wanted a tool that told you this stuff before it became a problem.
So I built depgraph — an open-source dependency intelligence platform that crawls npm, PyPI, and Cargo registries, builds a live risk-scored dependency graph, and tells you exactly which packages in your supply chain are about to cause you pain.
What it does
Risk scoring across 6 dimensions
Every package gets scored on security (open advisories, CVSS scores), maintenance (commit recency, release cadence), compatibility (semver violation rate), concentration (bus factor, single-maintainer risk), blast radius (how many downstream packages break if this one changes), and operational health (issue response latency, PR merge time).
These combine into a single composite score with full explanations — not just a number, but “35% because maintainer activity fell 80% in 120 days.”
Interactive dependency graph
Built with Cytoscape.js. Click any package to see its full transitive dependency tree, blast radius stats, and which packages it would take down if it disappeared. Chokepoint detection highlights the packages that are structurally too central to ignore.
Policy engine with CI gate
Define rules like “block packages with one maintainer and no release in 180 days” or “require approval for anything with 500+ downstream dependents.” A GitHub Action runs the policy check on every PR and fails the build on violations — with a formatted comment showing exactly what triggered and how to fix it.
Abandonment detection
Time-series signals track commit frequency trends, maintainer count decay, and bus factor over time. A weighted model produces an abandonment probability score per package so you can see which ones are quietly dying before they become your problem.
Historical snapshot diffs
Every scan creates a full risk snapshot. Compare any two snapshots to see which packages degraded, which improved, what new vulnerability chains appeared, and how your overall supply chain health changed over time.
Tech stack
TypeScript monorepo with pnpm workspaces. Hono API, React + Vite frontend, PostgreSQL + Drizzle ORM, BullMQ workers, MinIO for raw storage. Fully self-hostable — one docker compose up and you’re running. Zero paid services required.
Supports npm, PyPI, and Cargo with a shared normalization layer that maps all three ecosystems to a canonical data model.
Running it locally
bashgit clone https://github.com/zaydmulani09/depgraph
cd depgraph
pnpm install –ignore-scripts
cp .env.example .env
docker compose up -d
pnpm db:migrate
pnpm –filter @depgraph/api dev &
pnpm –filter @depgraph/crawler dev &
pnpm –filter @depgraph/ui dev
Open localhost:5173. The crawler seeds 10 packages immediately and starts processing — within a few minutes you’ll see risk scores, graphs, and explanations populating in the UI.
What I learned building this
The hardest part wasn’t the risk scoring or the UI — it was maintaining a living graph. Getting data once is easy. Keeping it fresh, detecting drift, diffing snapshots, and making all of that fast enough to be useful is where the real complexity lives.
The second hardest part was normalization. npm, PyPI, and Cargo all have wildly different versioning semantics, dependency specifier formats, and registry API shapes. Building a canonical model that works cleanly across all three took longer than any other single component.

Check it out, open issues, and PRs are welcome.
GitHub: https://github.com/zaydmulani09/depgraph

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post

Why your B2B PPC metrics may be lying to you

Next Post

PCN24 Update: BINDT/PCN introduces Dual Certification for Levels 1 and 2 in MT, PT and VT

Related Posts

網紅程式設計師回應炒股一年虧130萬:當流量主體走進散戶敘事,虧損也成了內容

一位擁有技術背景的網紅程式設計師公開承認一年在股市虧損約130萬人民幣並回應爭議。本文拆解事件經過、散戶在高波動市場的結構性劣勢,以及科技自媒體與投資敘事的邊界。 Techroomage 編輯部 · 2026年7月1日 · 閱讀約 8 分鐘 一年虧掉130萬。當這個數字出現在一個以理性、技術背景為人設的網紅程式設計師身上,它不再是單純的帳面損失,而變成了一則被演算法與留言區共同咀嚼的內容事件。微博熱搜「網紅程式設計師回應炒股1年虧130萬」之所以快速發酵,在於它踩中了一個尷尬的對比:一個理論上最懂數據、最擅長建立模型的羣體,在公開市場裡依然難以免疫散戶的宿命。 TL;DR 一位在微博具有相當關注度的網紅程式設計師公開回應「炒股一年虧損約130萬人民幣」的傳聞,承認虧損屬實並對外說明。事件折射出科技自媒體人物把個人投資經歷內容化的新趨勢,也再次暴露散戶在高波動市場中的資訊劣勢與情緒管理難題。 事件經過 熱搜話題源於這位程式設計師在社羣平臺上揭露自己過去一年累計虧損約130萬人民幣的紀錄,隨後引發大量轉發與討論。當事人隨後親自下場回應,針對外界質疑做出說明。 需要強調的是,130萬這個數字來自當事人自述與微博話題傳播,並未經第三方財報或券商資料獨立核實;其部位結構(個股、ETF、是否含融資槓桿)也未有完整公開。引用時應保留這層不確定性,避免把自述數字當成可查證的財務事實。 關鍵事實(條列) 事件主角:一位在中國社羣平臺具有技術人設、被網友稱為「網紅程式設計師」的內容創作者 關鍵數字:自述一年累計虧損約130萬人民幣(來源為當事人公開發言,未經獨立核實)…
Read More