posted 2016-07-07 12:40:00 -0500
nom is a replacement for the central npm registry, driven by the mildly cataclysmic events of 2016. As an avid node.js developer, I was disheartened both by the legal action which pushed Azer to unpublish his modules, npm-the-company’s response to his unpublishing, and the deep flaws in the npm registry which these events exposed. With nom, I’m looking to create a registry which both deincentivizes the kind of legal action which took place, and which responds sensibly when it does.
Fully open-source, npm-compatible repository implementation
100% scoped packages. Non-scoped packages will never be supported or permitted
No support for user unpublishing (this is not the same as immutability, since it doesn’t address litigation). Most reputable package repositories do not support unpublishing.
Zero name reuse. A package with name @org/package will always refer to that package, or result in an HTTP 451 Unavailable For Legal Reasons.
Broken builds (with a proper response code) are the correct and expected result of a missing package - not the silent and unintended installation of a different package under the same name, regardless of version tag.
Backwards compatibility. To maximize adoption, this registry should be compatible with the existing npm client (at least npm install), and package.json
Courting and/or forming an open, transparent governance body to administer the repository
Courting major/popular npm package authors to publish their packages on nom (in addition to npm, or exclusively if they so wish)
A full blog post about nom and its motivation is coming soon, but for now, go here for more information.