Isn't this typical of what you get when you have a language that's easy for newcomers to pick up?

At one point it was PHP. Then it was Rails. Of late it's been Node. I'm sure Windows users might have some old VB war stories. (Admittedly, I'm not sure what to make of the Java StackOverflow tag, seeing that it's also is a sewers. Presumably school or Android related.)

Edit: good related reading:

http://yosefk.com/blog/redundancy-vs-dependencies-which-is-w...

> Redundancy sucks. Redundancy always means duplicated efforts, and sometimes interoperability problems. But dependencies are worse. The only reasonable thing to depend on is a full-fledged, real module, not an amorphous bunch of code. You can usually look at a problem and guess quite well if its solution has good chances to become a real module, with a real owner, with a stable interface making all its users happy enough. If these chances are low, pick redundancy. And estimate those chances conservatively, too. Redundancy is bad, but dependencies can actually paralyze you. I say – kill dependencies first.

That is an excellent quote that says so much of what I've been trying to convey to my peers for some time, but much terser and more eloquently. Thank you for sharing!

Note that this goes for all levels: variables, functions, methods, classes, namespaces, libraries, software packages, systems, business (world?).

Guys, let's be honest, there are also:

[1] https://api.jquery.com/jquery.noop/

[2] https://lodash.com/docs/#noop

[3] http://underscorejs.org/#noop

[4] http://reactivex.io/rxjs/file/es6/util/noop.js.html

[5] https://docs.angularjs.org/api/ng/function/angular.noop

edited: formatting

Let's me help you to add more in the list:

https://github.com/sindresorhus/noop3

https://github.com/yoshuawuyts/noop2

https://github.com/supershabam/nop

https://github.com/mattdesl/no-op

Those are not modules afaik

There needs to be a TypeScript definition file accompanying it, as well as an Angular module so that I can import it via dependency injection.

Lets write a React component for it, quick!

    import {noop} from 'node-noop'

    export default () => <noscript>{noop()}</noscript>

The `<noscript>` had me laughing out loud in the coffee shop.

This one is also nice: https://github.com/sindresorhus/noop3 It has a noop factory :-)

See also the issues: https://github.com/sindresorhus/noop3/issues

What's up with the funky labels?

It's called Zalgo [1]. I'm surprised that GitHub allows Zalgo characters in the issues.

1 : https://eeemo.net

There is no such a thing as zalgo characters. It is plain unicode (utf-8 shaped), in particular it is an abuse of combining characters. Disabling those can cripple non-english languages.

It's possible to look at how "overloaded" the combination characters are and trigger a filter if above a certain level.

I doubt non-english languages quite overload as much as "zalgo" generators.

I'm actually not sure where the term Zalgo comes from. I know the effect is abused Unicode feature, but was never sure how does the term "Zalgo" end up explaining it.

I really want to assume this is a joke - and yet I'm left totally uncertain!

Yes, it is a joke, check the tags at the github repo:

  ironically-shitty
  javascript
  left-pad-level-dumb-module
  noop
  parody
  satire

It is, however the npm package "noop" that it mentions seems to be actually used...

https://www.npmjs.com/package/noop

> 202 downloads in the last month

> Dependents (3): meta-noop, scrappers, npl

> 202 downloads in the last month

Usually, a 100 of those would be from bots by sites that also host npm package information.

https://www.npmjs.com/package/meta-noop is 10 months old and got only 6 downloads last month, so I don't think it's entirely background noise.

https://www.npmjs.com/package/scrappers which depends on noop looks like an actual, real, useful package.

// Here we benchmark node-noop against various other things that are known // to do nothing to see if we have the fastest way of doing nothing.

As long as we discuss noops, JavaScript provides one out of the box as `Function.prototype`. It can be called and does nothing.

No need to create a new function object when you need a noop.

And it's even immutable. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

~So functional~

This is nice. Now we finally have a template npm project for everything, with no side-effect.

While this is an extreme case of course, packages by themselves are quite cheap (apart from installing times), and usually if the author tries to keep the dependencies in check it doesn't really create a mess.

In practice though, even the smallest toy project will pull out hundred tiny dependencies.

This is why funny stories like leftpadgate can happen.

Relying on an external dependency is a net win if and only if the time gain overcomes the loss of control.

Maybe regrouping all these tiny libraries under an umbrella project (lets call it node-utils or js-tinytools or whatever) will mitigate the problem?

This project will not have any external dependency though will be used by most of the projects and ergo might be watched with much more attention.

> In practice though, even the smallest toy project will pull out hundred tiny dependencies.

I had a problem with running out of inodes on my server because of the massive number of files that end up in node_modules for even a smallish project.

NPM caused horrendous issues in my dev environment a while back. I was developing on a Windows 7 machine with my Node environment in a VirtualBox VM. I was keeping my code in a VirtualBox shared folder so I could edit it in my IDEs on the windows side and then easily run `npm install` etc. on the linux side.

Turns out, the combination of vboxsf and ntfs masquerading as a linux filesystem is not without bugs-

Sometimes, the directory depths that npm reached caused the filesystem to "soft crash", where it would just fail to do operations on files, meaning you had to run `npm install` a few times to actually grab all the dependencies.

Other times, it caused the host machine to blue screen.

One of the times this happened, it had the side effect of irreversibly corrupting my favourite programming font (Fira Code) for all JetBrains IDEs on that Windows install.

Not so much a problem now I'm not being forced to develop in Windows. But even though I dug up bugs in unrelated pieces of software / the host OS kernel, npm was still pushing that software to the limits with that crazy recursive directory structure it was attempting to build.

You don't get this shit with python!

No kidding? This is impressive!

Did you write about it somewhere?

This happens constantly on older versions of Docker.

Another classic is installing one dependency with NPM and having it blow up because it's hit the 255 character limit for file paths on Windows due to nested dependencies.

Grouping all these tiny libraries under an umbrella project will just end up like PHP. No consistency, and various levels of repetition and redundancy and quality.

Having them separate like this at least means that if one library doesn't implement things 'right' you can switch to another easily.

PHP lacked the namespacing in the first place, which made the API messy and flat.

Look at python (or ruby)'s standard library, it's awesome, and of high quality (most of the time, see urllib/requests for a counterexample).

> Relying on an external dependency is a net win if and only if the time gain overcomes the loss of control.

Everybody should remember this

No, leftpadgate happend because you can delete packages from npm. The size of the package is irrelevent.

I keep thinking we've reached peak npm, but node.js keeps surprising me. :)