Back to blog
FILE 0xE0·TWO CLICKS TO MONITOR YOUR WHOLE OPEN-SOURCE STACK

Two clicks to monitor your whole open-source stack

June 9, 2026 · oss, micro-saas, python, npm, side-project

The friction in "watch this repo" tools is always the same: you have 200 dependencies and the product makes you add them one at a time. Nobody does it. The tool sits empty and you wonder why you signed up.

I built OSS Pulse to monitor open source dependencies for health signals — CVEs, maintainer departures, license changes, repos going dark. But for months the "add a repo" flow was just a text box that took owner/repo. Functional, but high friction.

Last night I built dependency import: paste your package.json or requirements.txt, click "Resolve," check the boxes for what you want to watch, click "Add." Done.


How it works

The core of it is two resolver functions:

def _parse_npm_repos(package_json_text: str) -> list[dict]:
    pkg = json.loads(package_json_text)
    all_deps = {}
    for section in ("dependencies", "devDependencies", "peerDependencies"):
        all_deps.update(pkg.get(section) or {})

    results = []
    for name, version in list(all_deps.items())[:50]:
        repo_id = None
        url = f"https://registry.npmjs.org/{name}"
        req = urllib.request.Request(url, headers={"Accept": "application/json"})
        with urllib.request.urlopen(req, timeout=5) as resp:
            data = json.loads(resp.read())
        repo_url = (data.get("repository") or {}).get("url", "") or ""
        m = re.search(r"github\.com[:/]([^/]+/[^/.]+?)(?:\.git)?$", repo_url)
        if m:
            repo_id = m.group(1).lower()
        results.append({"name": name, "version": version,
                         "repo_id": repo_id, "found": repo_id is not None})
    return results

For npm: look up each package in the npm registry, extract repository.url, match a GitHub URL pattern. For pip: same thing via PyPI's JSON API, checking project_urls under several keys (Source, Repository, Homepage, Code).

The resolution rate in practice is around 70–80%. Some packages don't publish a GitHub URL; a few point to GitLab or Bitbucket. Those show up as found: false and get filtered out before the checkbox list appears.


The npm registry as a GitHub URL database

This is the key insight: the npm registry is already a reasonably complete mapping from "package name" to "GitHub repo." Every package that publishes correctly has a repository.url field. The ones that don't are either vendored code or packages from before everyone used GitHub.

Same pattern applies to PyPI — project_urls in the metadata is where maintainers put their canonical links.

Neither API requires auth for this. 50 packages = 50 HTTP calls = about 5–8 seconds total.


The backend endpoint

def handle_import_deps(event: dict) -> dict:
    body = json.loads(event.get("body") or "{}")
    import_type = (body.get("type") or "").lower()
    content = body.get("content") or ""

    if import_type == "npm":
        packages = _parse_npm_repos(content)
    elif import_type in ("pip", "requirements"):
        packages = _parse_pip_repos(content)
    else:
        return error(400, "type must be 'npm' or 'pip'")

    resolved = sum(1 for p in packages if p["found"])
    return response(200, {
        "packages": packages,
        "parsed": len(packages),
        "resolved": resolved,
    })

I cap at 50 packages per import to keep response time under 10 seconds. That covers 95% of real projects — the packages at positions 50+ in a dependency list are the deeply transitive ones you probably don't need to monitor directly.


The frontend

The dashboard has a collapsible import panel with a textarea, a type selector (package.json / requirements.txt), and a Resolve button. After resolution, it renders a checkbox list with the package name and version alongside each resolved repo ID. Select all, add — done.

The "Add selected" button calls the existing POST /api/repos endpoint. No special import pathway — the import is just a UX layer on top of the existing add-repo flow.


Stack health summary

While I was in there, I also added GET /api/stack-summary: one call that returns your aggregate stack health score (weighted average of all repo health scores), counts by tier (healthy / fair / at-risk / archived), and the top-3 repos you should look at first.

The dashboard now shows a summary card above the repo list — a single number that tells you whether your open source dependencies are in good shape or need attention.


What's next

The import flow currently resolves packages to their current GitHub repo. The next useful thing is to cross-reference the pinned version in the user's dependency file against the package's latest and the GitHub release history — so OSS Pulse can tell you "you're 4 major versions behind on this package, and it had a CVE in version 2.x."

That's the conversion moment: you paste your package.json, you get back a list that includes "hey, you're pinned to lodash@3.x and there were 2 CVEs fixed in 4.x." You upgrade. You pay for the product.

OSS Pulse is in private beta. If you want early access: chester@cwfrazier.com.