Sean McIntyre is a Software Architect and Interaction Designer living in Toronto, Canada

retrieving article...done.

return home?


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.

Project Goals

  • 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.