This is a guest post for the Computer Weekly Developer Network written by Burke Holland in his capacity as director of developer relations at Progress — the firm is a specialist in backend application build tools, PaaS technologies and (now with the acquired Telerik) it also offers tools for building the interface on the front end.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Holland writes as follows…
While the concept of packages in software is as old as software itself, there has been a turn towards ‘micro packages’ in the past two years. These micro packages are libraries that are miniscule in scope, some containing only one line of code.
Too many packaging systems
Even Microsoft has built NPM support into its tooling. Packages on NPM vary in capability. Some are enormous in feature and scope, such as NativeScript, which is an entire runtime for building mobile apps. While it doesn’t ultimately run on Node, the tooling is built via NPM.
Another example is the Angular CLI which pulls down 966 NPM libraries just to build an Angular application.
NPM has done such a remarkable job of package abstraction, making applications more modular than ever before, even if nobody has realised it. Such ease in package management doesn’t come without trade-offs though. When developers use NPM packages they are taking a dependency on them, meaning that if the creator decides to remove their package, this could cause some problems.
This was seen with the LeftPad scandle of 2015. The developer unpublished a module that did nothing but pad using a specific number of arguments. However, this package was used everywhere and as a dependency in other popular libraries such as Babel. While this won’t ever break a production build, it did cause widespread consternation by developers trying to setup new projects with a non- existent LeftPad dependency.
Taking the dependency tradeoff
Taking dependencies is itself a tradeoff – a developer sacrifices control for productivity. However, it’s a tradeoff worth making.
Productivity is the lynch pin around which a developers’ success revolves. In order to solve common problems (making an AJAX call, handling a server request, left-padding a string), developers use already published solutions that can be found in NPM.
When other developers need the same functionality, instead of having to write and test it, they can simply include a package which has already been written and tested. This ensures that they don’t have to reinvent the wheel every day.