Software Galaxies renders package manager dependency graphs in 3D

A registry drawn as a galaxy rather than a dependency list

Package managers hide their most interesting property. A lockfile tells you the shape of one project's dependencies, but the wider shape of a registry stays invisible: which packages sit at the center, which ones are pulled in by hundreds of others, which corners of the ecosystem are barely touched by anyone. The pm project, published under the name Software Galaxies, exists to make that structure visible.

The repository describes itself as combining visualizations of major software package managers, and the hosted version at anvaka.github.io/pm/#/ offers one galaxy per ecosystem. The visual metaphor is a 3D field where each package becomes a node and the links between packages become edges. A galaxy for npm looks different from a galaxy for Debian because the underlying graphs are different, not because the viewer is configured differently.

The origin is documented too. The repository was created for a talk at CascadiaJS 2015, and the README links the conference video and the slides. That origin explains a lot about the shape of the code, which is a decade-old React application rather than something rebuilt on current tooling. The idea has aged better than the stack, and the online demos remain the primary way most people meet the project.

Each ecosystem gets its own indexer, and the data lands on gh-pages

The visualization is not the same thing as the data, and the README is explicit about the split. Individual graphs are indexed individually, and the results are pushed to the gh-pages branch of a separate repository, galactic-data. The viewer then reads that published data.

Each ecosystem also has its own indexer project, and the README links them next to the demos. Bower has allbower, PHP Composer has allcomposer, Ruby gems has allgems, npm has allnpm, the Go ecosystem has allgo, and the R language index is allcran. Debian has alldebian, NuGet has allnuget, Homebrew has allbrew and PyPI has allpypi. Fedora is listed with its own indexer as well. Arch Linux is the interesting exception, because its indexer is not under the anvaka account but points at phiresky/crawl-arch, and it appears twice, once for Arch Linux alone and once for Arch Linux including the AUR.

This structure has a direct practical consequence. If your registry is not in that list, there is no galaxy for it, and building one means writing or running a separate indexer that produces data in the format the viewer expects. The visualization layer is reusable; the graph extraction is per ecosystem, and that is where the real work sits.

The view state lives entirely in the URL

The demo links carry a long list of query parameters, and reading one tells you how the navigation works. The Arch Linux link includes cx, cy and cz for the camera position, lx, ly and lz for the look direction, lw for the field of view, ml for a distance limit, s for a scale factor, l for a layer or mode flag, and v for a variant such as no-aur or including-aur.

That is the whole navigation model in practice. The camera is expressed in spherical-like angles rather than a position, which is what lets a huge graph stay navigable: you orbit rather than fly. The parameter set is stable enough that the README links for Debian, Homebrew, PyPI, Fedora and Arch all carry the same shape, and the R language link uses the same scheme with a different starting camera.

The project also asks readers to read an operating manual, linked as the documentation, and describes it as short, covering basic navigation principles. That framing is honest about the scope: this is a graph you fly through, and the manual exists because the control scheme is not obvious. It is also a reason the URLs are worth keeping. A particular vantage point over the npm galaxy is a link you can paste into an issue, a talk, or a document, and the view reopens exactly as it was.

The Arch variant flag shows the value of that sharing. The same camera and the same graph, with and without the AUR, are two different URLs, which makes a comparison between the two package sets something you can hand to someone else rather than something you describe.

Running the viewer locally with the npm start script

The package is named pmviz in package.json, and the development entry point is a small Express server driven by webpack-dev-server. The scripts section gives you two commands worth knowing:

"build": "mkdir -p ./build && cp ./src/index.html ./build/ && webpack -p --config webpack.production.config.js",
"start": "PORT=8081 node dev-server.js"

The start script pins the port to 8081 and launches dev-server.js, which is at the top level of the repository alongside webpack.local.config.js. The build script creates a build directory, copies src/index.html into it, and runs webpack with the production configuration. Both configurations are checked in, so a local build does not need configuration invented by the reader.

The dependencies explain the rendering approach. ngraph.generators, ngraph.events and the maco layout library cover graph generation and layout, while three.orientation, webgl-enabled and unrender point at WebGL based 3D rendering, with unrender pulled directly from a git URL. React at 0.14 with react-router at 1.0 handles the application shell and the routing between the different galaxies, and less with less-loader handles the styles.

The test script is a placeholder that prints an error and exits with status 1, so there is no test suite to run. The repository also contains a deploy.sh and a start-windows.cmd, which tells you the project was set up to be built and served on Windows as well as Unix.

A 2015 stack with no releases behind it

The dependency versions are the honest part of this project. React 0.14, react-dom 0.14, react-router 1.0, webpack 1.9, babel-core 5 and babel-loader 5, bluebird 2.9 and bootstrap 3.3 all date from the same era. A fresh install of this package.json pulls a dependency tree that current tooling no longer supports comfortably, and a contributor picking this up today would spend their time on migration rather than on the visualizations.

Maintenance is thin in the documented sense. The repository is not archived, and the last push was on 2026-06-24, so work does happen on it, but there are no GitHub releases, no version tags to pin, and no changelog describing what a given commit changed. The version field in package.json still reads 1.0.0, which reflects the package name and shape rather than a release train.

The licence is MIT, which is the permissive end of the spectrum and makes reuse of the viewer code uncomplicated. That covers the visualization layer. The data is a separate matter: the graphs are produced by indexer projects living in other repositories with their own licences, and the README does not state what terms apply to the published data on the gh-pages branch of galactic-data.

The practical reading is that this is a data visualisation with a long life ahead of it as a hosted site, and a codebase that is closer to a historical artifact than to a maintained library.

Hosted demo versus running an indexer yourself

There is a real choice here, and it is not a matter of taste. The hosted Software Galaxies at anvaka.github.io/pm/#/ gives you every galaxy that has been indexed, with the data already built and the camera already set. Nothing needs to run on your machine, and the operating manual is the only thing you have to read.

Running the viewer locally is for a different purpose. If you want to work on the visualization code, to change layouts or rendering, or to test a change against a dataset, you need the local server and a webpack build, and that is where the old dependency versions become your problem.

A third path is the one the project structure implies. If the ecosystem you care about has no indexer, you write or adapt one, push the result to the gh-pages branch of galactic-data, and point the viewer at it. The Arch Linux case shows that outside contributors do exactly this, with the crawler living in a separate repository under a different account and the same viewer rendering the result. That path is the most work and the most reusable, since a new indexer is the one piece nobody else can supply for you.

For a reader who just wants to know what the npm dependency graph looks like, the hosted demo is the whole answer. For someone who needs a current graph of a registry, none of these three paths guarantees freshness, because the data is rebuilt only when someone rebuilds it.

Editorial conclusion

Use pm when you want to see the shape of a registry, for example to find a dense cluster of packages in Debian or to trace how a library connects to the rest of an ecosystem, and accept that the hosted graphs are snapshots rather than live data. Do not adopt it as a dependency resolution tool, since it draws relationships and does not resolve them, and skip it if you need a maintained release train, because the repository publishes no GitHub releases and its package.json still pins React 0.14 and webpack 1. Verify first that the ecosystem you care about has an indexer project, because the galaxies that exist are exactly the ones with a matching indexer in the list.

Frequently asked questions

Official sources

1. anvaka/pm on GitHub
2. Issues
3. License: MIT
4. Project website
5. README