The reason is that many people don't know how to write a proper isArray. Forgetting about security momentarily (and I promise we'll come back to it), rewriting code repeatedly is a path towards bugs and mistakes. Array.isArray didn't even exist until pretty recently, and was non-trivial to understand before then (x => x && Object.prototype.toString.apply(x) === "[object Array]", of course!). There's an entire separate discussion of why JavaScript doesn't build this stuff in to begin with, but now we're in historical land and not practical solution land.

Ultimately though, the goal needs to be to build tools where its hard to do something insecure regardless of how we otherwise feel about that programming practice. It can't be that the reason we shouldn't install is-array is because it can lead to catastrophic exploits -- that says something about the ecosystem not the validity of where we choose to draw the line of what merits a library.

Node is cursed in part by its success. In a lot of ways its like the early days of the web, it grew faster than we had time to figure stuff out in. That's OK if we learn quickly and adjust accordingly. We don't have to run node program's with access to everything -- but again, we don't have to run any kind of program with access to everything. Go to Homebrew's website (https://brew.sh). This is a developer tool and what they tell you to do is to blindingly copy a bash line that downloads a file from THE MASTER BRANCH on GitHub and runs it on your system:

    /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Get access to this guy's password and you can compromise tons of systems too. As much as I hate the Mac App Store as a distribution mechanism, there's something to the "sandbox first" programming mentality it incidentally forces its apps into. Maybe we should be thinking more along those lines too.

Importing lots of code from others is a path towards bugs and mistakes. You end up not understanding your dependencies, importing far too much (because you want function x but also get a-z), amd dealing with changes you didn't want or need which mix security fixes with features.

Better to minimise dependencies particularly for trivial functions. Not just for security but for ease of development.

I love node - it's a really irresponsible way of programming. The objective is to make as much the concern of someone else as possible. "How do I know what an array is? I'm just writing this app that works with arrays.."

:-)

In seriousness though, there many ways to write an isArray. Just yesterday I was looking at the different things String::repeat() handles on Mozilla's site. What seems trivial can be defined slightly differently everywhere and I tend to reach into the npm bag if I know it's open to interpretation.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

    /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Ignoring the obvious stupidity here, why does it invoke Ruby only to invoke curl?

That's not what it's doing. It's downloading Ruby code and then running it. The "$(...)" is evaluated first.

It curls the install script, which is passed to ruby as a string which is run.

Ah, duh, you're right. I forgot $() is bash syntax and not the Ruby syntax for running an external command. Thanks, and yikes.

Because the install script is in ruby?

Perhaps npm packages should be dockerised to prevent this.

> from THE MASTER BRANCH

to be fair, there's nothing particular about the branch called 'master'.

The point is that you just have to engineer your way to commit access on master once. If it at least pointed to a github release or an immutable equivalent, it'd be vetted by the author before millions of people point a ruby eval at it.

I never really understood the true appeal of micromodules, but they are especially unappealing in the face of the combinatorial explosion of dependencies and the attack surface they bring with them. I mean if you want a left pad or an is array, is pulling in something established and trusted like lodash really that bad?

They make a lot of sense to people who like to think functionally. If you view modules as providing functions that you can composite into whatever it is that you need, micromodules are appealing because they offer just want you need and nothing more.

>micromodules are appealing because they offer just want you need and nothing more

But people don't import micromodules, they import entire dependency trees of arbitrary depth full of micromodules. The greater simplicity of the modules ironically leads to greater complexity in practice.

You're right.

Personally, I think this is an example of a failure of some people to appreciate the consequences of their preferences.

Just because they are "hackers" it does not mean they know how to program. There are a lot of "hackers" that actually suck at it.

I suppose hacking is its own business domain, and these are domain experts writing shitty code to implement the business logic they need.

I've known programmers who couldn't program very well, but they understood the business domain and its rules so well that, while writing verbose unmaintainable crap they could be as productive as better programmers who did not know the domain as well.

Hence why NPM exists in the first place.

Is there a formal, npm-style registry for reusable snippets like this? It would be great to have a popular, well known registry of snippets where they could be named, searched, voted on, ranked, written about in top-10 articles, etc.

> formal, npm-style registry for reusable snippets like this?

> popular, well known registry of snippets

> named, searched, voted on, ranked, written about in top-10 articles

https://www.npmjs.com/

?

For snippets, not modules.

Closest I know is: https://30secondsofcode.org/