
Ask HN: Why All the Hate for NPM? - gitgud
Every time NPM (node package manager) gets mentioned people are quick to point out flaws:<p>- Large dependency trees<p>- 100&#x27;s of Mb of code for hello world react projects<p>These seem like superficial problems, from what I can tell the system encourages:<p>- Software reuse (maybe too much)<p>- Bundling source with the package
 (good for verification)<p>- Easy to contribute to the ecosystem<p>- Fast resolution of modules<p>Do people just hate NPM because it&#x27;s JavaScript?
======
dangerface
Most of the complaints I have heard are about the developers using their
position of power to push their own political agenda.

In the past they have ripped off some ones copyrighted code when it was a
dependancy for everything[1]. After that they then deleted other peoples
packages claming copyright infringement because there partner wanted the
package name[2]

A lot of people moved to the faster alternative yarn, this caused the NPM
developers to rain in their bull.

Their past actions and how they wield power are a demonstration that they
should not have it, their attitude is one rule for us and another for everyone
else.

[1]
[https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)
[2] [https://kodfabrik.com/journal/i-ve-just-liberated-my-
modules...](https://kodfabrik.com/journal/i-ve-just-liberated-my-modules/)

~~~
gitgud
> Most of the complaints I have heard are about the developers using their
> position of power to push their own political agenda.

If a developer is the authority on a package, they should be able to do what
they want right? Not sure why this is a bad thing, people can fork the project
if they don't agree with the changes. Or just use previous versions.

What's the alternative? A single authoritarian political agenda?

> A lot of people moved to the faster alternative yarn, this caused the NPM
> developers to rain in their bull.

Yarn is just another CLI tool, it doesn't have its own packages and connects
to the NPM repository.

Also, it's now extremely hard to remove or change a version of a package on
NPM...

~~~
dangerface
I was referring specifically to the developers of NPM and provided links to
examples of them abusing their power.

Yes creating a non authoritarian fork is the only effective alternative, which
is why I mention yarn. Yarn might not solve all of the problems with NPM but
it showed the NPM developers that people would build alternatives if NPM
pushed them to it.

In response NPM has lifted a lot of yarns features and improved its speed.
Despite not being perfect it was at least affective enough as an alternative
for NPM to notice and fear.

------
xs83
I think a lot of it stems from the fact that many javascript developers
blindly use packages for the most basic of things.

The Left Pad mentioned above is a prime example - do you really need a
dependency for that? Start adding nested dependencies and well it's simply a
mess!

~~~
gitgud
The Left Pad incident was a huge wake up call for the community, but not for
the reasons most people state (dependencies are bad! why not write it from
scratch!).

Rather, it shows that dependencies should really be immutable, at least
versions of dependencies anyway. It seems it's no longer possible to remove a
package from npm, you're only able to deprecate it. Which means _Left Pad_
cannot happen again, in this way.

Software reuse is an important part of progressing technology and I think it
should be encouraged... or at least made easy...

~~~
stephenr
You think it’s logical to have an entire module to do

foo % 2 === 0

?

What about another module to call the first one and invert the return?

Development based around npm modules is a joke

~~~
gitgud
It's not logical, but it should be possible to do something trivial in a
package.

What's the alternative? Allow only packages with code over 100 lines? 1000
lines?

Packages are an excellent way to share code, regardless of complexity...

~~~
krapp
>What's the alternative? Allow only packages with code over 100 lines? 1000
lines?

The alternative is allowing packages with more than a single function. It's
NPM and the javascript development culture which is enforcing the arbitrary
limit of "no more than a single function per package."

Sure, you _can_ do trivial things in a package, but that calls into question
the usefulness of enforcing that level of granularity versus having libraries
of related functions, shallower dependency trees and less fragility.

~~~
gitgud
What about libraries like npm packages like Lodash which contain a collection
of small helper functions right? You might have to import everything from the
package though...

I suppose it's similar to the Unix philosophy, " _do one thing and do it well_
". Also don't forget that people can _repackage_ these fine grained tools into
a single library package too.

~~~
krapp
That's fine. But the cultural acceptance of single-function libraries is still
a problem. Before NPM, it wasn't even an issue - plenty of javascript
libraries and jQuery plugins were being distributed that way.

Why does a function to check if a number is even need its own namespace, and a
dependency on another namespace which tests if it's a number at all, and a
third to check if it's odd? What's the benefit to this?

>I suppose it's similar to the Unix philosophy, "do one thing and do it well"

Any philosophy can be taken too far.

~~~
gitgud
> Why does a function to check if a number is even need its own namespace, and
> a dependency on another namespace which tests if it's a number at all, and a
> third to check if it's odd? What's the benefit to this?

The benefit is modularity, separation of concerns and versioning but in this
case it's ridiculous...

 _Any philosophy can be taken too far_

That should be printed on my office wall!

------
gus_massa
Remember " _How one developer just broke Node, Babel and thousands of projects
in 11 lines of JavaScript_ "
[https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

~~~
gitgud
True, but it's now no longer possible to remove a package from npm, which kind
of solves this module resolution problem.

However a malicious actor could still upload a _broken_ minor version that
most node projects would try to automatically resolve to, and thus break...

~~~
dangerface
> which kind of solves this module resolution problem

Your exception is not limited to malicious actors as even ligitmate packages
like uglifyjs have had to do this. The NPM developers themselves have no
problem deleting packages which would result in the same problems. They solved
their problem by pushing it onto the rest of us.

------
iraldir
On top of what's been already mentioned, a lot of people are starting to not
trust NPM because it is a for profit business, dependant on investor's money.
It might not be here forever, it might be bought by some other actor etc. It's
also a giant attack vector. Create a popular package or buy or get ownership
from a developer of a package, and you can easily hide code in the mified
deployed build while not having in the source code. Using complexe hiding
methods, you can hide code in a subsubsub dependency of something that will,
say, copy input fields and send them via XHR, every 100 times and not when
debugger tools are open, or only when you detect you are in a country where
the targeted developer is not located etc. Even worse for nodejs libraries.

------
djhaskin987
Where to start.

Probably the two biggest arguments are bloat[1] and broken builds. Both seem
to be caused by an obsession with the culture of "never reinvent the wheel"[2]
which can be stifling and over-the-top, especially given a community so
willing to publish backwards incompatible changes come hell or high water.

Both of these -- ease of publishing breaking versions and making libraries
that are 11 lines long for the sake of not repeating them -- may have
something to do with how npm manages dependencies. That is, it doesn't. You
ask for a specific version of a library and you get it. Simple. You don't
share this code version other libraries on the system. It sort of makes it
easy to do the wrong thing, like backwards incompatible changes. For another
example, this can cause problems when library B and A get results from calling
library C and then communicate to each other using those results. You see, A
uses C at a completely different version than B does. You end up with madness,
and two copies of C (bloat).

Contrast this with maven. Yea, lots of small libraries, but maven only allows
one version of a library to exist and doesn't tell you exactly which one it
will pick [4]. This is horribly broken BUT encourages people to NOT write
backwards incompatible stuff. It encourages a healthy community. Maven central
doesn't receive nearly as much hate as npm in my experience

Then there's the crypto mining incident[3], but that could arguably have
happened in one of several communities, really.

[1]:
[https://twitter.com/tdvorak/status/678613940746756096?s=19](https://twitter.com/tdvorak/status/678613940746756096?s=19)
[2]: [https://xkcd.com/2140/](https://xkcd.com/2140/) [3]:
[https://link.medium.com/UVCo1GTaaW](https://link.medium.com/UVCo1GTaaW) [4]:
[https://maven.apache.org/guides/introduction/introduction-
to...](https://maven.apache.org/guides/introduction/introduction-to-
dependency-mechanism.html)

~~~
ezekg
> especially given a community so willing to publish backwards incompatible
> changes come hell or high water

This triggers me. I feel like I dealt with this issue almost on the daily (ok,
ok -- weekly) until we fully moved to yarn and started freezing the lockfile
[0] with:

    
    
      yarn --frozen-lockfile
    

It really is ridiculous. And even with yarn, I still have multiple resolutions
[1] in our package.json files due to breaking changes in patch versions
without a fix.

[0]:
[https://yarnpkg.com/lang/en/docs/cli/install/](https://yarnpkg.com/lang/en/docs/cli/install/)
[1]: [https://yarnpkg.com/lang/en/docs/selective-version-
resolutio...](https://yarnpkg.com/lang/en/docs/selective-version-resolutions/)

------
quickthrower2
In defence of NPM it is Javascript that lacks a decent core library like you’d
get with .Net or Java, you just get the very basics in the J.S. language
(where as most languages have even less in the language but bundle a good
class library). This means you need leftpad, moment, etc. stuff you don’t need
in .net or Java.

