[Gnolfo]

I totally agree. The npm ecosystem and the generally accepted practices in js these days come close to the bash style of composing & chaining a bunch of solid, specific little programs together to solve problems trivially that would have been a bear to do in many other platforms like java, C++, etc. I cringe at the idea that you should find yourself implementing l-pad in 2016, at least for the vast majority of projects that a typical engineer will encounter in their career. A similar case can be made for something as small as "is positive integer".

While I agree, there are two counter arguments:

1) As noted in other comments, this is a reflection of the core libs of javascript not covering enough of the basics. This is a subjective thing when it comes to where to draw the line, but wherever the border lies between "core" and "community" libs, on the other side you start running into things like "L-pad" and "Lib-L-Pad" and "L-pad2". If there's a great enough fundamental need, you experience a lot of crowding where lots of people offer up their solution to this, and reconciling that across larger dep. chains that disagree on which one to use can become a real burden.

2) Have you ever had the conversation with an auditor (PCI, HIPAA, etc) that your application is actually built on top of a huge substrate of software written by unaffiliated 3rd parties? And that between your own iterations you could easily have different versions for any/all of them? It's a difficult conversation. Much less the explanations to QA about why a build failed because lib X was updated to a new hotfix version in the 14 hours since yesterday's build, after a couple hours of wasted time of initially suspecting your own diffs, and trying to navigate through all the indirection between the actual stack trace and what actually caused the blow-up...