
The Node.js Ecosystem Is Chaotic and Insecure - wheresvic1
https://medium.com/@caspervonb/the-internet-is-at-the-mercy-of-a-handful-of-people-73fac4bc5068
======
Klathmon
Oh come on...

> Nonsense dependencies are hard if not near impossible to manually audit due
> to the sheer number of them.

Why do you need to audit dependencies you don't use? Don't use `is-odd`,
nobody is forcing you too.

If you aren't able to audit a 20 line file and determine it's worth to you,
then maybe you shouldn't be installing any dependencies at all.

The existence of garbage doesn't mean the system is broken, or that the
ecosystem is "chaotic and insecure". It means that it's inclusive, and anyone
can make a package, no matter how terrible you might think it is.

~~~
megaman22
I have no less than seventeen different point releases of lodash buried in my
node_modules directory for one project. That's completely insane, but every
plugin we use for something has it's own massive tree of dependencies, which
have their own dependencies, ad absurdum, until I've got paths too long for
Windows to be able to delete down in there.

Not to even get into the clusterfuck that is semver and how the default
behavior with npm isn't to pin to a specific version of a package. It's bitten
me in the ass several times lately because some dependency of ours will have a
new _patch_ version, and it completely breaks everything.

I'm living mostly on the back-end, .NET world. NuGet isn't great, but it's a
breeze compared to fighting with JS-land. Packages are kept to a reasonable
size, rather than fragmenting into micropackages, references only update when
you tell them to, and stability is valued. Of course, you've also actually got
a standard library, so you don't have to rely on third-party code for basic
functionality.

~~~
styfle
You might find Package Phobia[0] useful. It determines the size of a package
before you install it including it's dependencies. Disclaimer: I wrote it.

Another good tool to use before you pull in a dependency is this dependency
visualization[1].

[0]: [https://packagephobia.now.sh](https://packagephobia.now.sh)

[1]: [https://npm.anvaka.com](https://npm.anvaka.com)

------
joshenglish
I think this article has seen HN a few times.

[https://news.ycombinator.com/item?id=16785396](https://news.ycombinator.com/item?id=16785396)
[https://news.ycombinator.com/item?id=16720011](https://news.ycombinator.com/item?id=16720011)
[https://news.ycombinator.com/item?id=16900545](https://news.ycombinator.com/item?id=16900545)

------
Can_Not
I find this article to be one year late malicious hyperbole and completely
useless in redeeming itself with appropriate action items.

> Node modules are widespread and ripe for abuse.

Most package systems kind of are, especially when they become more useful.

For real advice: checkout from npm retire and auditjs (there's also more non
free options). You'll likely get some false positives (such as, who would host
jQuery on a public/untrusted cdn? or why would you even pass user input into
that?), but if a real malware actually showed up, you can find out as part of
your CI process. Using the lockfile provided by yarn/npm is also a good way to
reduce accidental unnecessary package updates.

> Nonsense dependencies are hard if not near impossible to manually audit due
> to the sheer number of them.

No, they are easier to audit. It's a lot easier to verify that leftpad isn't
installing a Bitcoin miner than to verify react isn't installing a Bitcoin
miner. React is probably the size of 1000 leftpads, too.

> Manually audit and lock down your dependencies.

No mention of what this is suppose to be. Yarn will lock your dependencies by
default. The yarn.lock file will have the exact version locked. I haven't used
npm in a while.

> Stop using nonsense dependencies, writing basic code is not reinventing the
> wheel.

Yes, writing "basic code" is reinventing the wheel. You have at least 10 free
fully tested leftpads available on npm but you expect me to write one more?
I'm paid to build the application, not to apply non-sense rules. This outrage
over microlibraries needs a bit more substance. Your alternatives are
basically "write code that already exists" or "use bigger monolithic
libraries", and, to be frank, most of us have used other languages before or
worked on multiple projects, and we can decide for ourselves if a function
should be in in-housed or npm'ed. For something as basic as leftpad, wasting
time writing it is just a waste of time. As a hard rule, this rule is garbage.
As a soft rule, it's not very useful, as case by case scenarios vary too
wildly in terms of complexity and significance.

------
tokenizerrr
All of these packages are created by Jon Schlinkert
([https://github.com/jonschlinkert](https://github.com/jonschlinkert)). So if
you want someone to blame...

~~~
nailer
[https://github.com/jonschlinkert/is-
odd/blob/master/index.js](https://github.com/jonschlinkert/is-
odd/blob/master/index.js)

Edit:

the original code, even before the float handling, was was a perf
optimisation:

    
    
        !!(~~i & 1);
    

Nobody wants to see that in code unless it has a name. Maybe isOdd(). Maybe we
should put it on GitHub to save others time. Sure beats copy-pasting from
StackOverflow.

Original:

Did you think of handling floats in your home built isOdd implementation?
Thankfully Jon (EDIT: or one of his contributors - doesn't change the point)
did. And they added tests.

The (flagged) article makes the staggering assumption that "we can't code"
because we're not constantly reinventing the wheel. It talks about DRY being
taken too far and talks about the functions being replaced as "one liners",
when following a couple of links would show they're not. We can code, we're
just coding on actual features, not rewriting the same poop.

~~~
fenollp
No he did not. [https://github.com/jonschlinkert/is-
odd/commit/dcc7eeff5be8f...](https://github.com/jonschlinkert/is-
odd/commit/dcc7eeff5be8f8190e2a7e63b76eae2992ad854f)

~~~
Klathmon
Isn't this evidence that the system is working?

Because it's a package, a bug/oversight was found, and it was made more
robust.

I still wouldn't personally use `is-odd`, but isn't this proof that having
something even this trivial as a package can have benefits?

------
teliskr
The universe is chaotic and insecure

~~~
emodendroket
Maybe so, but that doesn't really address the concern.

~~~
hungerstrike
The article already addressed its own concerns:

\- Manually audit and lock down your dependencies.

\- Stop using nonsense dependencies, writing basic code is not reinventing the
wheel.

~~~
emodendroket
Except that if your dependencies in turn use nonsense dependencies you're back
to the problems.

~~~
hungerstrike
Should we not count dependencies that are comprised of nonsense dependencies
as nonsense themselves?

In my opinion, fork it and fix it or stop using it. Also, warn others if you
have the capacity.

~~~
emodendroket
left-pad broke non-trivial projects like Babel, as I recall.

~~~
hungerstrike
Yep, but there’s a big difference with how I treat dev and production
dependencies. I wouldn’t use something nearly that large in production.
Typically I look at a dependency to see if I could maintain it myself if
necessary because it’s always risky to depend on a third-party.

------
vortico
Doesn't specifying a "version" in your package.json completely solve this
problem? Can an author replace a package without changing its version on npm?

~~~
Klathmon
>Can an author replace a package without changing its version on npm?

No, and now both npm and Yarn have lockfiles, meaning you lock in the exact
version of all dependencies (including transitive dependencies).

The ecosystem saw the issues that were starting to crop up, and fairly quickly
created solutions that are now in widespread usage.

~~~
specialist
I have a great deal of antipathy towards npm and lock files.

I don't understand how rerunning shrinkwrap can change the roster. And I don't
care enough to spend any more effort trying to figure it out. (Meaning, fresh
out of goodwill.)

Maybe yarn is better. I kicked its tires; seemed okay. Alas, we have too many
(more than zero) nodejs projects to do a clean switch, and I'm tired of
pushing rope.

But even if yarn is better... I just can't grasp how we got to this point, or
how any one involved thought any of this was acceptable, on any level.

~~~
Klathmon
Well luckily newer versions of npm and all versions of yarn handle the
lockfiles for you, no extra effort required at all.

If you install something, it will find and lock the dependency versions at
install time. When you update that dependency, it will repeat then lock in
again. You actually have to go out of your way now to not use lockfiles in the
js ecosystem.

And if you really do have some js projects, take 30 minutes and look into
yarn. Not only is it significantly faster in my experience, but it's also
mostly a drop-in replacement and provides some much needed features like the
ability to install while offline from a local cache, and interactive upgrade
tools.

~~~
specialist
Belated thanks to you & paulddraper. Just yesterday I learned about NPM 6.x's
new lock files.

I'll suspend disbelief and give it another whirl.

~~~
Klathmon
That's great! But I would like to give you a warning that I personally don't
use npm any more. While they have improved leaps and bounds, in my opinion
they are still far behind yarn in many areas.

Yarn has deterministic installs, an offline cache (the recent yarn/npm
registry downtime of like an hour didn't stop our devs from reinstalling
dependencies because they were in the offline cache), fantastic tooling around
license checking and validations, and the workspaces system which makes it
significantly easier to work with massive monorepos with multiple sub-
packages.

If you are in a willing mood, and are already spending the time to try npm
again, I highly encourage you to give yarn a shot as well. You can install it
with `npm install yarn --global` if you want to just try it out (they have a
ton of more robust install methods to choose from if you want to permanently
switch), and aside from some different names (like you use `yarn add
dependency-name` instead of `npm install dependency-name --save`), it's mostly
a drop-in replacement and can even happily work alongside npm (one of the
packages I maintain we provide both an npm lockfile and a yarn lockfile quite
easily, while using yarn internally).

Hell just last week I used yarn to force a transitive dependency (it was like
4 levels deep in my dependency graph) to upgrade to a version which fixed a
security issue in a library I maintain, then put that in the lockfile so all
users that install that dependency through my package now get the updated
version by default.

Still, kudos for being open to trying it again! npm has never been the best
package manager by any account, but the one thing they do really well is
improve.

------
ahmetkun
What else is new?

