
The Node.js Ecosystem Is Chaotic and Insecure - unicornode
https://medium.com/p/73fac4bc5068
======
naranha
Almost all programming languages now have similar standard package managers. I
still remember back in the day when everybody would joke about how Maven
downloads the whole internet on the first build. This is still true today for
Maven, NPM, pip, composer, you name it. You are downloading hundreds of
packages for which you implicitly trust their maintainer to not do anything
shady. In case of Maven - and likely most others - packages are not even
digitally signed by the publisher and on top of it are binaries, that you
cannot easily inspect. I'd argue NPM is slightly better than that, at least it
(often) includes the source code, though you still have illegible instructions
in form of minified/uglified code.

I think NodeJS already has a decent stdlib and there will always be the need
to pull dependencies in for basic functionality (apache commons, guava etc. in
the Java world). That's just how OSS works. There should be a simple way to
display and verify the chain of trust though.

~~~
strken
NodeJS has a feature-rich standard library, but it's let down by poor
ergonomics. Compare, for example, the built-in http library[0] with request-
promise[1]. I think the difficulty of using the standard library makes NodeJS
devs feel better about downloading lots of little helper libraries.

[0]
[https://nodejs.org/api/http.html#http_http_request_options_c...](https://nodejs.org/api/http.html#http_http_request_options_callback)

[1] [https://github.com/request/request-promise#cheat-
sheet](https://github.com/request/request-promise#cheat-sheet)

~~~
WorldMaker
I think a lot of it is NodeJS settling on its standard library a bit ahead of
the larger language ecosystem itself. Promises were standardized shortly after
Node bumbled into a callback-heavy design. The efforts on the ES2015 Module
syntax occurred after Node settled for "CommonJS" which wasn't all that common
at the time.

Node's HTTP library as a specific example, particularly suffers from callbacks
instead of promises. It also suffers here in that it also predates the Fetch
standard making its way into browsers now.

Hopefully the Node standard library will continue to converge with the overall
JS ecosystem and catch up to the work that the Browsers have been leading
here.

------
pavlov
In my view the core problem is the complete lack of standards and interfaces
around what constitutes a “package”, “module”, “library” or even “framework”.
(It’s an industry-wide problem, not just JavaScript.)

In npm’s single global namespace, “is-even” is a package. So is the Firebase
SDK, even though the former is a single line of code and the latter is around
70 MB. But a package can also be something that’s not even JavaScript code:
maybe a CSS “framework”, or that infamous dictionary text that gets replicated
a dozen times in any large npm-dependent project because some popular package
uses the text in its tests.

If hardware parts were distributed like this, there would be no standard
fittings, nothing would be categorized. A hardware store would just be an
enormous pile of jumbled parts and tools. “Oh, you need a bolt? No problem,
John will jump into the pile with scuba gear and bring you some packages that
look suitable. It’s going to take a few days, hopefully we’ll find something
that fits.”

~~~
treve
What are you looking for exactly? A category system? The argument seems kind
of weird. A bit similar to how a .zip file might contain just a few things,
but also a lot of things. I think it's kind of a good thing that the same
delivery mechanism can be used for various things, but I'm guessing you have a
problem with discoverability?

~~~
pavlov
The problem affects not just discoverability of new dependencies, but also
development and maintenance of settled dependencies.

When you see a line like this in package.json...

    
    
      "dependencies": {
        "foobarfrobblizer": "^0.9.31",
    

There's no simple way to determine what foobarfrobblizer does, where it's
actually used in the app, what side effects it may perform when called, what
dependencies it pulls, why it was included, and whether it could be replaced
with something else that offers a similar API.

For a single package, I can figure all this out manually. But projects these
days are seriously dependency-binged. If I use "create-react-app" to make a
Hello World web app, it gives me 150 MB of stuff in node_modules. I'm never
going to look at even 1% of those packages to see what's actually in there.

I got started in programming when a dependency meant either a DLL file
provided by someone else, or a static library that you manually link into your
executable. Taking on a new dependency was a big decision: do I really want to
rely on this DLL file being there for me, or having to carry this separately
built binary blob in my project? I still get that same dread when I have to
add an npm package to a project, but it doesn't seem like most people feel
that way.

On top of those DLL files 25 years ago, there were systems like Microsoft COM
that let you use them interchangeably through standard interfaces. You could
make a plugin UI component that works seamlessly in Visual Basic by simply
conforming to a COM interface. It even worked from multiple languages: that UI
component could be written in C, C++ or Object Pascal if you wanted.

The web development ecosystem has a long way to go before it matches the
usability of 1995 desktop development — and that's a painfully low bar.

~~~
askmike
> Taking on a new dependency was a big decision: do I really want to rely on
> this DLL file being there for me, or having to carry this separately built
> binary blob in my project?

I'd argue that the NPM ecosystem (although not perfect, hence OP) is a lot
more evolved specifically because of how easy it is to include a wide range of
dependencies.

The speed with which you can write software is an awful lot higher, and (if
done properly) you can rely on safe dependencies that are tested and used by
everyone else. Why reinvent the wheel in every project?

~~~
raarts
> you can rely on

This is exactly the problem.

Given the current ecosystem, you can't and shouldn't. You are just proving
GP's point.

------
pluma
Comparing is-odd with left-pad is a bit disingenuous.

Left-pad had a fairly trivial implementation but that implementation is easy
to get wrong, so it's something you want to make sure you have covered by
tests and you want to define the edge cases. It's something that should be
(and as of ES2017 is) part of the language and not something you want to keep
reinventing (alongside all the edge cases and potential for annoying bugs).

The is-odd and is-even packages OTOH are blatantly ridiculous. I had a look in
my dependency tree and it seems is-odd made its way into it via a package
called "nanomatch" which used is-odd because the maintainer apparently was of
the opinion that (to paraphrase) "if it's difficult enough to get wrong on the
first attempt it's difficult enough to warrant delegating to a dependency" \--
which he seems to have taken to the logical extreme.

That said, the package in question removed the dependency on is-odd after what
seems to have been a lot of negativity about his decision not to inline the
logic previously:
[https://github.com/micromatch/nanomatch/pull/11](https://github.com/micromatch/nanomatch/pull/11)
so once that change propagates through the dependency tree, it should at least
no longer show up for some people.

~~~
twexler
> Left-pad had a fairly trivial implementation but that implementation is easy
> to get wrong, so it's something you want to make sure you have covered by
> tests

...What? That makes no sense. `left-pad` is trivial to implement and test.
There may be edge cases but for most people, writing tests to cover the edge
cases they care about rather than pulling in a dependency just to handle
something as simple as padding a string.

Not to mention, Node's near-complete lack of a standard library is at fault
here, not developers, nor the ECMA technical committee.

~~~
pluma
> `left-pad` is trivial to implement and test

There's a tangible difference between `value % 2 === 1` and this:
[https://github.com/stevemao/left-
pad/blob/master/index.js](https://github.com/stevemao/left-
pad/blob/master/index.js)

You're not even contradicting me. I said it has a fairly trivial
implementation and you concede that it has edge cases. You're just disagreeing
on whether that warrants using an external dependency rather than writing it
yourself (and writing all those tests yourself too).

> Node's near-complete lack of a standard library is at fault here, not
> developers, nor the ECMA technical committee.

So you think String.prototype.padStart should have been a Node built-in module
rather than a language feature? Are we talking about the same language that
also has String.prototype.italics and String.prototype.bold?

There's nothing Node could or should have done about the lack of string
padding. Node's "standard library" is first and foremost concerned with
enabling network and filesystem IO. JS on the other hand even lacks a built-in
way to handle dates properly (the Date class is largely an afterthought based
on Java).

String.prototype.padStart deserves to be a language feature and it should have
been a language feature from the start. Most other languages provide this out
of the box. The reason these things end up on NPM is not that JS developers
are idiots but that they don't want to reimplement the same basic utility
functions every other language would offer as a standard library or copy
folders of code around.

Yes, this is absurd when it comes to things the language actually DOES offer
(or basic maths like `value % 2 === 1`) but for the most part NPM is
fulfilling JS developers' need for a standard library -- and that's entirely
on not just Node but also the language itself (and by extension TC39).

EDIT: It's worth pointing out that left-pad has zero dependencies, as it
should. Compare this to is-even (i.e. `value % 2 === 0` as a function) which
depends on is-odd which depends on is-number -- all written by the same author
and 100% serious.

~~~
coldtea
> _There 's a tangible difference between `value % 2 === 1` and this_

No, there isn't. Both are trivial to write and avoid an external dependency.

Besides, the implementation leftpad doesn't have to be this crappy -- one can
do it in 3 lines.

------
jannes
What disgusts me the most about the JS ecosystem these days is that even the
most basic developer tools have tons of depencies.

Let's say you want to use webpack and TypeScript on a project: Boom. 425
packages installed. And that's before you have written a single line of code.
(It's probably worth noting that the offender is webpack. TypeScript seems to
be dependency-free.) [1]

Every single one of those 425 packages could have a malicious postinstall
script that deletes your entire home directory or sends your private ssh keys
to a remote server.

npm makes it too easy to add dependencies to a library.

[1]: If you also want webpack-cli that's another cool 441 packages for you.

~~~
aolagers
This. Even with minimal applications your node_modules is so full of stuff
that you need external tools for reviewing your dependency graph.

But TypeScript is a positive exception to this trend. It has no (npm)
dependencies at all.

~~~
kakwa_
I remember trying to play a little with node and vue.js a few months ago (I'm
a devops/backend developper by trade). Having seen the size of my node_modules
directory, nearly 1GB, I was kind of horrified (to be fair, I checked most of
the testing options, so a lot of the libraries were coming from that).

------
Sir_Cmpwn
This is a large part of why, in my opinion, language-specific package managers
are generally bunk (though language-specific packaging tooling is not
necessarily so). I install all of my Python packages system-wide through my
distribution's package manager, and if no package is available I make one.
Distribution packages are cryptographically signed and reviewed by a
dispassionate human being before being published, and are available on mirrors
around the world to mitigate the single source of failure language
repositories tend to suffer from.

Of course, this is difficult for something like Node, whose package ecosystem
is out of control.

~~~
badosu
Assuming we could avoid the legacy leverage, would it be possible to build or
use an already existing package manager to perform this, wrapping all specific
logic for each language?

~~~
Sir_Cmpwn
The human element is important imo. I don't think automating it away is wise.
However, many distros have tools for speeding the work for particular
languages.

------
kuschku
What I'm interested in — most open source licenses such as MIT require that a
copyright notice is preserved for each dependency, direct or transitive. Many
licenses even require that such copyright notices for all dependencies are
shown in an about menu in the software.

How do you do that with node.js projects? Do you just have an about screen
with 15'000 licenses and copyright attributions in your software? Do you just
violate the license?

~~~
caspervonb
For Node.js projects, the MIT clause should be covered by simply having the
entire package installed, provided the author actually put the license file in
the package.

However when using a bundler; you are potentially violating the licenses of a
bunch of packages.

~~~
kuschku
It also becomes an issue once you’re building a web application, as you’ll
have to present it in the UI.

------
wyqydsyq
yet-another-article-talking-about-the-left-pad-incident-and-fragile-
dependency-chains-in-general-with-a-sensationalized-clickbait-title

~~~
movedx
Are you are JavaScript developer, out of interest?

------
suprfnk
I am absolutely flabbergasted that the `is-odd` package on NPM [1] was
downloaded 3 million times last week. In any project, a check for an odd
number would half the time not even have its own _function_.

Even an aggressive build server that redownloads and builds 50 times a day
would require 60.000 separate installs...

Does anyone have any reasonable explanation for this?

[1] [https://www.npmjs.com/package/is-odd](https://www.npmjs.com/package/is-
odd)

~~~
stupidcar
Correctly checking if a variable is odd is not quite as simple in a dynamic,
type-coercing library like ECMAScript as you might think. You have to consider
things like: is the variable null or undefined? Does it have the Number type?
Is the number an integer? Is the integer odd? In a statically typed language,
the compiler would guarantee many of these things for you, but in ES you need
to do it yourself.

It's not rocket science, but it's tricky enough that you could perhaps make a
mistake or overlook something. To be safe in these situations, when writing a
small amount of "nearly trivial" code, programmers have generally resorted to
a package manager called "Google / Stack Overflow".

This package manager works as follows: You Google for "safely check if odd in
JavaScript", open the top Stack Overflow link, then copy and paste the answer
(usually a single function) into your codebase. Then you add a comment saying
"taken from [https://stackoverflow.com..."](https://stackoverflow.com...").
Whenever you have another piece of "nearly trivial" code to write, you install
it the same way.

ES developers thought that this workflow could be optimised a bit. To that
end, they invented a package manager called "npm". Unlike the Google / Stack
Overflow manager above, this lets you install functions like "is-odd"
_without_ having to manually copy and paste them from your browser. It also
keeps track of where they came from, who authored them, and even lets them be
updated, if necessary.

~~~
charliesome
> You have to consider things like: is the variable null or undefined? Does it
> have the Number type? Is the number an integer?

This is a non-problem. If you really have to consider all these edge cases
before testing if a number is odd or even that's a sign you need to seriously
rethink your domain model, not reach for a library that has already thought
about these edge cases for you.

Well written dynamic code should be mostly statically typed.

------
Blackstone4
What is the alternative?

Have the large projects maintain their own dependencies? i.e. React, Webpack,
Typescript, Express...

Create and maintain your own packages?

Review each package and save a copy in your own repo for re-use? Upgrading
would be a pain.

~~~
krapp
>Have the large projects maintain their own dependencies? i.e. React, Webpack,
Typescript, Express... >Create and maintain your own packages? >Review each
package and save a copy in your own repo for re-use?

Yes? It is possible for things to be _too_ convenient, IMHO.

>Upgrading would be a pain.

Upgrading should be at least a bit painful. Upgrading without pain means you
don't really know what changes you're making to your codebase, and you don't
care to know, you just want the magic black box to work and not bother you
with the details. There should be at least more effort put into upgrades than
the least amount possible.

------
emilsedgh
I think Node.js ecosystem is like a big desert.

There are true gems and treasures you can find but it's mostly useless.

------
jariz
Yes, so let's all keep reinventing the wheel, over and over again.

I know the author uses pretty extreme examples, but I still don't see what's
inherently wrong with the mentioned packages.

\- it does what you think it does:

`isOdd(2)` is a lot easier to understand than `value % 2`

\- even though most of these are one liners, it's one line of code less that
you have to maintain

\- if the package is at least somewhat popular, it's highly likely it has
measures for edge cases; stuff I wouldn't have thought of when writing it
myself.

On top of that, mentioning left-pad is really cliche and weak at this point
(bear in mind this happend 2 years ago), npm has taken measures and nothing
similar has happend since then, and even then, it was still a fairly isolated
event - the whole thing actually took 10 minutes.

I'd much rather take a rare, yet-to-happen-again chance that a package goes
down, over having to rewrite simple utility functions over and over again,
every month.

~~~
goatlover
> isOdd(2)` is a lot easier to understand than `value % 2`

Isn't modulo something basic every programmer should know about?

~~~
cannedslime
is-odd package doesn't use modulus. And I don't think thats really the issue
either. is-odd has three dependencies of its own, one being is-number...

~~~
caspervonb
Splitting hairs, yes that uses bitwise operators, you can get away with either
a modulus operator or a bitwise AND operator.

------
gyaru
>because no one locks down a dependency like is-string to a patch version.

Is this actually true? Is this not what "package-lock.json" is intended to
solve?

(Not primarily a javascript developer)

------
z3t4
This is utopia, with software virgins, all collaborating, sharing and reusing.
Please don't destroy this paradise.

------
rdiddly
Literal LOL (LLOL? It'll catch on yet) at the existence of both is-odd and is-
even!

------
latchkey
npm might even install a dependency without you realizing it (typo).

[https://github.com/npm/npm/issues/20072](https://github.com/npm/npm/issues/20072)

------
politelemon
Shouldn't the main concern highlighted here already be taken care of with
package-lock.json and yarn.lock? They record the dependency trees, so a rogue
package update should not really affect you.

~~~
scintill76
Assuming you audit what was locked, and audit whenever you update, then yes.
I'd be worried a coworker would go on an update spree just because they can,
and wouldn't audit the new code.

~~~
ralusek
Yes but then you're no longer grappling with the limitations of the ecosystem.
Introducing a rogue developer who updates dependencies irresponsibly is a
danger in any language.

~~~
caspervonb
Who _really_ audits every single dependency in their dependency tree? not so
much a rogue developer, but most.

~~~
xfer
If you are hobby programming, then not really, but in most workplaces,
dependencies are usually pinned and not updated until necessary(bug fixes
mostly).

~~~
caspervonb
From what I've seen as a contractor usually there is no package-lock at all.

------
fbn79
I say unto you: one must still have chaos in oneself to be able to give birth
to a dancing star. I say unto you: you still have chaos in yourselves. FN

------
baybal2
The "modern" JS ecosystem:

1\. Over-reliance on tooling. JS was made as a scripting language, if you
can't use it as such, its purpose is lost. And that tooling works against
betterment of the ecosystem - lib authors rely on tooling to fix issues of the
platform, rather than seeking a definite solution.

2\. Any serious JS project is a long term maintenance burden. The prevalence
of "single line libraries" makes future-proofing of the code impossible. You
don't only have to version-freeze your immediate dependencies, but
dependencies of your dependencies. You will have to manage their version
manually, it all becomes your own problem.

3\. Authors of JS VMs swear on their firstborns that JS performance has been
greatly improved, yet, it sucks. For practical purposes, JS code is barely as
quick as perl or python.

4\. Too much evals in 3rd party code everywhere. The only way you can secure
your front-end is to ensure no third party code policy on your page. When it
comes to the back-end, things become more grave. On the back-end, you can say
that there is no universal solution.

5\. Zoo of standards on the front-end, browser APIs changing on a whim.

6\. Zoo of sublanguages: Coffeescript, LiveScript ClojureScript, MoonScript,
AtScript, TypeScript. Having to mix anymuch of them in a single project is,
you can guess, a supernightmare.

Yet, I don't completely hate people who want to move JS forward. TC39 may well
be too heavy on being staffed by theoreticians, but they have right
priorities: standardization, having whatever going into the standard being
highly dry before even approaching the pre-standard status, enforcing a
semblance of synchronicity to the ecosystem.

What JS needs in my opinion:

1\. HARD VERSIONING

2\. Compliance certification through testing with a hard version

3\. An even harder enforced decoupling of the paper standard and
implementation. While the majority of modern JS implementations are VM based,
this should not make the standard to accommodate design decisions dictated by
a VM implementation.

4\. Readiness to do breaking changes in between major hard versions, and no
reservations for backward compatibility.

5\. Many browser APIs are de-facto parts of the standard library as such. They
need to be managed as a part of the standard.

~~~
realusername
There's some truth there in your comment but also a lot of wrong things.

> 1\. Over-reliance on tooling

Everything has tooling, I defy you to find a single language you can use in a
medium-size project without any tooling, good luck, I don't know any.

> 2\. Any serious JS project is a long term maintenance burden. The prevalence
> of "single line libraries" makes future-proofing of the code impossible. You
> don't only have to version-freeze your immediate dependencies, but
> dependencies of your dependencies

It's the same for any language. Yarn has a yarn.lock for this exact purpose,
for other languages you will have [your language package manager].lock, it's
the same.

> For practical purposes, JS code is barely as quick as Perl or python.

It's currently 3 times faster than Python and the gap is only widening every
year. You picked the wrong languages to compare the speed, at least you could
pick Rust, Go or C++.

> 5\. Zoo of standards on the front-end, browser APIs changing on a whim.

It's getting better with vendoring nowadays and the core features are there
everywhere. You only need vendor-specific APIs if you build something
specific.

> 6\. Zoo of sublanguages: Coffeescript, LiveScript ClojureScript, MoonScript,
> AtScript, TypeScript

Only TypeScript is alive nowadays, all the others are kind of dead so this
isn't true. Also MoonScript is for Lua so it's not even related to Javascript.

> 4\. Readiness to do breaking changes in between major hard versions, and no
> reservations for backward compatibility.

Most features are not backward compatible, that's why you need to use some
tooling. You cannot have no tooling and no breaking changes at the same time.

~~~
baybal2
>Everything has tooling, I defy you to find a single language you can use in a
medium-size project without any tooling, good luck, I don't know any.

On my memory, large projects on PHP and Python falling into that category are
all around the place

>It's the same for any language. Yarn has a yarn.lock for this exact purpose,
for other languages you will have [your language package manager].lock, it's
the same.

No it isn't. Heck, the prime example of a "fragile language" \- C, doesn't
have these issues take to such extremes even on the most complex and projects
thanks to good developer culture omnipresent emphasis on API compatibility,
and good API design. Gtk+ for examples has huge list of dependencies, yet, not
as single time my code failed to run properly because Gtk's own dependencies
somehow influenced my code. This is not due to lack of data structures,
objectized data is being used all around modern C.

>It's currently 3 times faster than Python and the gap is only widening every
year.

No, the figure that you are giving is for synthetic benchmarks that do nothing
more than arithmetics with primitive data types. I would like to see
performance figures a tree sort or merge with complex data structures. The
performance will suck equally.

>You cannot have no tooling and no breaking changes at the same time.

When you forego backward compatibility for the benefit of this approach, you
do not resort to perversions with tooling to bring it back, resulting in a
worse result.

~~~
pluma
> No it isn't.

It isn't because most other dependency managers don't allow dependencies to
bring their own versions of other dependencies, instead you're stuck with
version conflicts preventing you from upgrading to a recent version of library
X because you're also using library Y and both libraries have a dependency on
library Z (but the new release of library X uses an incompatible version of
it).

I was a Python developer in a previous life and in any Django project this
would eventually happen and require you to either replace these unmaintained
dependencies or ignore their version requirements and pray for the best (which
was usually a gamble because semver wasn't a thing).

------
kumarvvr
Why would WebPack require to use a package like "is-odd" or "is-even"??

~~~
caspervonb
Indirectly through it's vast dependency tree.

------
kabes
So if I'm releasing an is-odd pip package, does that mean the python ecosystem
sucks?

~~~
strken
No, but if flask or pip or some other widely-used piece of the python
ecosystem pulled in unmaintained packages, trivial packages, or very large
package trees, it might make the python ecosystem chaotic and insecure.

------
sbr464
Click bait, move along

~~~
movedx
Are you are JavaScript developer, out of interest?

~~~
sbr464
yes

~~~
movedx
I'm not the author of the article, but could you expand on why it's click
bait?

Personally, I think NPM is a crazy, mental concept. As a Go developer (so
mostly server-side work) I can't fathom the amount of deps that are pulled
from NPM when I'm working with or watching a JS code base being used. I assume
server-side NodeJS code bases are the same their front end cousins in terms of
deps pulled(?)

~~~
sbr464
Hi, appreciate the followup, apologies for the previous short comment.

I feel like it's clickbait, not worth reading, for these points:

1\. Even if the argument is valid, the points made in this article have been
expressed, shared, (whined about?) probably 9+ times in my own reading. It's
really time to move on.

2\. There is nothing inherently wrong with using small/simple modules. Once
you start to reuse code in many projects, the value becomes clear. Some are
juicy and complex, some are eye-bleeding simple. It's better than copying and
pasting code around folders. Use org modules/private modules and the problem
is solved.

I absolutely believe that npm is ripe for *potential abuse, although I have
yet to have any issues.

No one has time for Breitbart-esque fearmongering, or the regurgitation of
stale points while an ample selection of real world problems exist to be
solved.

Jeez that reads harsh. Apologies, it's late.

~~~
movedx
> apologies for the previous short comment. > Jeez that reads harsh.
> Apologies, it's late.

All good, friend.

> ... It's really time to move on.

But is it? I fear that if this is a genuine issue, why would I want to move on
from it? Essentially npm is enabling people to build bridges in the same way
steel is helping people to build actual bridges. If there was a flaw in some
steel production process, I wouldn't ignore it. People could suffer.

Extreme(?) examples a side, if it's an issue, why not aim to solve it? This
seems to pop up a lot, so perhaps it's time for a (long-term) solution?

> Use org modules/private modules and the problem is solved.

Yes! This is where I personally see the long-term solution: pick your top-
level deps, (permanently) cache them locally and validate them, then
implement/use them. Only update the cache when you're confident the remote,
official copy has been changed in a manner that's safe for you and or your
users.

> I absolutely believe that npm is ripe for *potential abuse, although I have
> yet to have any issues.

How do you know you've not had any issues? If I was attacking you via some
sort of "side channel" attack, like breaching and injecting bad code into an
NPM module I know you're using, how would you know it's happened?

Are you using a CI/CD process? The changes are high that you are and therefore
unless you've version/commit pinning, it's likely you're blind to those deps
being updated during your build process, enabling me to perform said "side
channel" attack.

> No one has time for Breitbart-esque fearmongering, or the regurgitation of
> stale points while an ample selection of real world problems exist to be
> solved.

If it's being regurgitated so much, perhaps it is a "real world" problem to be
solved.

~~~
Can_Not
> If it's being regurgitated so much, perhaps it is a "real world" problem to
> be solved.

I don't think most people deny that it's a problem or that it needs to be
fixed. But completely blown out of proportion with Breitbart-esque fear-
mongering is something that needs to stop. People still talk about "leftpad"
as if it wasn't fixed the same day, sometimes as if it were never fixed,
sometimes even as if it isn't even possible to write software in NodeJS. I
haven't seen a fair and factual comparison chart of npm vs pip vs crate vs
composer, and I'm calling BS that the majority of this "concern" is anything
more than trendy JavaScript-Hate until I see one.

