As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?
replies(11):
It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative also specified concrete modules such as the interfaces for node.js/express.js HTTP "middlewares" you can plug as routes and for things like auth handlers (JSGI itself was inspired by Ruby's easy REST DSL).
The reason for is-array, left-pad, etc. is that people wanted to write idiomatic code rather than use idiosyncratic JS typechecking code everywhere and use other's people packages as good citizens in a quid pro quo way.
[1]: https://wiki.commonjs.org/wiki/CommonJS
Edit: the people crying for an "authority" to just impose a stdlib fail to understand that the JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations; this concept seems lost on TypeScripters who need big daddy MS or other monopolist to sort it all out for them
It's not unique in this sense, yet others manage to provide a lot more in their stdlib.
It's not that you need a "big daddy". It's that the ecosystem needs a community that actually cares about shit like this vulnerability.
What is this crap statement?
So you want type-checking because it helps you catch a class of errors in an automated way, and suddenly you have a daddy complex and like monopolies?
Claiming this says a lot more about you than people who use TypeScript.