Thoughts on NPM and the Azer Debacle

DZone 's Guide to

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?

· Web Dev Zone ·
Free Resource

I’m in the middle of ramping up on Node.js for a client, an ecosystem I’ve resisted for a long time for multiple reasons. I’ve had fits and starts in trying this platform before and either quit out of just general dislike of JavaScript the language, dislike of node’s standard library, or just dislike of the general ecosystem. I lump NPM into that ecosystem. There has always been something about that platform that always struck me as some Frankenstein of amateur hour caked on top of something striving hard to be a serious platform development. However, I was finally putting that distinction aside—especially given lots of the tooling now being built on top of Node and my previous affinity for at least using mocha/requests for API testing.

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.

I realize that some fine granularity in modules stems from a culture of keeping JavaScript code actually delivered to clients at a minimum (NPM gets used for front-end tooling too) and a desire to keep things very independent, but Haney makes great points in his section that 'Functions are not packages'. My software’s dependencies should depend on packages that are each a self-contained bundle of functions, classes, and other language constructs that have a high level of cohesion, and whose cohesion allows the software I’m writing to accomplish a certain goal while allowing me, the developer, to avoid reinventing the wheel. Providing so little behavior in a module is an abuse of the packaging system and the repository from which it retrieves from—misusing both as a mechanism for network-enabled copy-and-paste.

Are These Things Deal Breakers?

No, probably not—I’ll slog on. But, it remains an open question as to whether NPM can evolve or if the ecosystem will rally around a more sane and comprehensive alternative. If the JavaScript and Node ecosystems do not actively work to address problems such as these, both from technical and cultural standpoints, then it’s a greater sign that the ecosystem really does not want to get serious about things that affect its reliability and maintainability as a first class platform to build software of all kinds on top of—and, that is a scarier prospect.

dependency management, ecosystem, node.js, npm, opinion

Published at DZone with permission of Jason Whaley , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}