Thursday, March 24, 2016

Let's not blame NPM and modular development over a hissy fit

This week a developer who was pissed off at NPMJS.org pulled all his packages, including one little strange package left-pad that was a dependency for a frightening number of other packages and software projects, including React ( see http://www.businessinsider.com/npm-left-pad-controversy-explained-2016-3 )


This caused us problems during a Travis CI build for a project for which we were using React on a project - it was a scary realization that anyone of the authors of the 100s of 1000s of packages in NPM can have hissy fit and withdraw their code. It confirmed for me that any packages we may use in prototyping and first-iteration need to be replaced locally (check those licenses - most of them are completely open or are MIT - copy/paste at will!).

In response there was fear and blame as you would expect. Then there were calls to change the very nature of the packages on NPM: http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program.

While I agree with the majority of the sentiment, the article makes a statement that I think is contrary to the whole idea of package management systems and shared code: "Functions are too small to make into a package and dependency."

Risks (that should be mitigated before going to production) aside, the idea really is about small building blocks: (from NPM) "These packages are often small. The general idea is that you create a small building block which solves one problem and solves it well. This makes it possible for you to compose larger, custom solutions out of these small, shared building blocks."

Personally, I avoid large frameworks (like React) as much as I can - our React project was an inherited development that we took on from the prototype stage and we were rather married to it (unwillingly).

No comments:

Post a Comment