Thoughts on NPM and the Azer Debacle
Author Jason Whaley shares his viewpoints on some of the negativity surrounding the Node.js ecosystem, especially as it relates to the recent Azer incident. Is it time to give up Node.js?
Join the DZone community and get the full member experience.Join For Free
However the recent NPM/Kik/Azer kerfuffle really validated some of my negative thoughts again about the Node ecosystem and has actually made me question my decision to devote time to this platform again—even if what I’m experiencing here is a purely knee-jerk reaction.
Much of the development world is discussing this exhaustively anyway, and there’s little I can say that hasn’t already been discussed, but here are a couple of immediate things that come to mind that gave me pause in this situation that I’m not seeing discussed widely, as of yet...
Lack of Namespaces/GroupIds
Spending most of my time in the Java/JVM ecosystem has spoiled me into forgetting just how important having a decent namespace mechanism such that names can (and must!) be qualified in both the language and in the build tooling. In the latter case, if NPM had the notion of groupIds or namespaces for dependencies, this whole issue would have been seriously mitigated, if not completely avoided.
Using the example of kik, an open source author could publish their module as io.github.user:kik, which would then have allowed Kik, the company, to not be blocked in actually publishing their module. A reasonably intelligent developer would very clearly see the difference between the two.
Under this scenario, if there was a squatting of the namespace identifier as well, then (assuming reverse DNS conventions) showing proof domain ownership would be a very easy course of action for the repository owner to follow in order to settle the dispute. If there was actually a trademark dispute, the two modules would still be allowed to live side by side until the one in error had a decent migration path, possibly involving only a mild rename.
Instead, what you have with NPM is just an environment where ease of publishing makes name squatting trivial—requiring large amounts of unnecessary vigilance—and results in inadequate policies like NPM’s which clearly could not address all that could have gone wrong.
Extremely Fine Grained Packages
Read this post from www.haneycodes.net if you have not done so already. There’s much to consider there, but I want to focus on granularity.
Deciding a proper amount of granularity is entirely more art that science and requires a lot of context to be known before being able to reason about what a proper amount of granularity for a given subject should be. But in this case, the level of granularity exemplified by modules on NPM in cases such as these is over the top:
There’s a package called isArray that has 880,000 downloads a day, and 18 million downloads in February of 2016. It has 72 dependent NPM packages. Here’s its entire 1 line of code…
There’s a package called is-positive-integer (GitHub) that is 4 lines long and as of yesterday required 3 dependencies to use. The author has since refactored it to require 0 dependencies, but I have to wonder why it wasn’t that way in the first place.
Are These Things Deal Breakers?
Published at DZone with permission of Jason Whaley, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.