Everything runs in your browser. The explorer walks the dep tree directly from the public npm registry JSON API and lays it out with dagre (vendored, no CDN).
Click a node to re-root the graph on that package. Every view has a shareable URL via the hash.
Native packages (orange dot) declare an os or cpu restriction in their manifest. The platform dropdown filters these: dependencies that don’t match the selected target are skipped entirely. Package names that obviously encode a platform (e.g. @esbuild/darwin-arm64) are filtered before even fetching. The common pattern — a wrapper package with many per-platform sub-packages wired up via optionalDependencies — is documented in Sentry’s publishing binaries on npm.
Attested packages (ring around the dot) carry an SLSA provenance statement published via registry.npmjs.org/-/npm/v1/attestations. Hovering the dot shows the repository, commit, and workflow file that produced the release, verified against the in-toto statement.
Caveats. Transitive dependencies always resolve to latest; exact semver solving is intentionally not done. The goal is to show what a fresh npm install with no lockfile would pull in. Sizes are unpackedSize from the registry (tarball extracted).
Everything runs in your browser. The explorer walks the dep tree directly from the public PyPI JSON API and lays it out with dagre (vendored, no CDN).
Click a node to re-root the graph on that package. Every view has a shareable URL via the hash.
Native packages (orange dot) ship more than one platform-specific wheel (anything other than -none-any.whl). This is a good proxy for packages that contain compiled code, but not authoritative.
Attested packages (ring around the dot) carry a PEP 740 attestation bundle published via pypi.org/integrity. PyPI currently ships “publish” attestations with a null predicate, so the build info (repository, commit, workflow file) is extracted from the Sigstore/Fulcio signing certificate itself rather than from an in-toto statement.
Caveats. Sizes are compressed wheel sizes, not installed sizes. Platform and Python-version markers in requires_dist aren’t evaluated, so e.g. colorama shows up on Linux even though it’s Windows-only. Transitive deps always resolve to latest.
Everything runs in your browser. The explorer reads the channel’s store-paths.xz index from channels.nixos.org (xz-decompressed live in the browser) and walks the runtime closure via narinfo files on cache.nixos.org. Rich metadata (description, license, outputs, platforms, maintainers) is pulled lazily from packages.json.br. Everything is cached in IndexedDB keyed by the channel’s git-revision, so subsequent visits are instant until the channel moves.
Click a node to re-root the graph on that package. Every view has a shareable URL.
Nodes are attribute paths, not store paths. Each node is one nixpkgs derivation (ffmpeg, python313Packages.torch, …). Its size is the sum of NarSize across the outputs that actually appear in the runtime closure, and its edges are the union of References across those outputs, mapped back to attribute paths. This avoids the per-output confusion where picking ffmpeg.out would leave you with just an empty placeholder. Hashes that Hydra didn’t build (bootstrap paths, unfree jobs, …) fall through as hash:<hash> nodes with the narinfo-parsed pname as their label.
Full closure accounting. The graph is visually capped at max nodes, but the “with deps” total walks every referenced store path for size accounting. The complete installed size is always reflected even when the graph is truncated.
Caveats. “nixpkgs maintainers” are the people maintaining the packaging recipe, not the upstream authors. The “nix source” link points at the .nix expression in nixpkgs pinned to the channel’s revision, not the upstream project’s code. Sizes are NarSize (compressed NAR) from narinfo. The “native” and “attested” distinctions don’t apply: every nix package is built from source, and narinfos are Ed25519-signed by the build farm key rather than carrying per-package SLSA-style provenance.
1 “native” is a heuristic. A package is flagged native if its manifest declares an os or cpu restriction. This is a good proxy for packages that contain compiled code, but it’s not authoritative. See Sentry’s publishing binaries on npm for context on why native packages are split into many per-platform sub-packages.
1 “native” is a heuristic. A package is flagged native if it ships more than one platform-specific wheel (anything other than -none-any.whl). This is a good proxy for packages that contain compiled code, but it’s not authoritative.
The nix graph shows the exact runtime closure: every store path the built output references. Sizes are NarSize (compressed NAR) from each package’s narinfo on cache.nixos.org. In Nix every package is built from source, so the “native” distinction doesn’t really apply and is left off.
2 An unattested package was uploaded directly by a maintainer, and there is no way to verify what code or toolchain produced it. See Npm Slop & Wonky Software Supply Chains for context.
2 An unattested package was uploaded directly by a maintainer, and there is no way to verify what code or toolchain produced it. See Npm Slop & Wonky Software Supply Chains for context.