npm2nix for example only uses npm to gather the the packages from the registry, but uses Nix for all the other stuff. [0]
[0]: http://sandervanderburg.blogspot.de/2014/10/deploying-npm-pa...
One of way of looking at Crom is that it provides a more convenient interface than a URL, yet without the centralization that comes from using names in a registry.
Crom helps you go from a name to a URL (via search heuristics), but it’s the URL that ultimately serves as the identifier. So, if you author a package.json with a name like “d3-format”, that gets expanded to a full URL, perhaps with interactive confirmation. (Or not, because it’s trivial to undo and redo.)
Also, unlike a URL to the ZIP file directly, a package URL in Crom supports semantic versioning: it refers to all versions of a project, and thus you can upgrade or specify a desired version range.
Probably the most important open issue is that simple names aren’t a sufficient identifier with a decentralized registry: you need a URL. So once Crom learns how to save package metadata, it should probably map any specified short name (e.g., `d3-format`) into a full URL (https://github.com/d3/d3-format) to ensure stability.
Mutable releases are also a concern, but Crom could save the hash of installed packages so you’d know if anything changed. And of course, since it’s decentralized, you could still have third-party registries that make immutable copies, if that’s your thing.