Hacker News Reader

Comment by oefrha | Hacker News Reader

Ah, the infamous npm spammer jonschlinkert. This guy has even crazier packages like https://www.npmjs.com/package/ansi-red and I quote:

  Related projects
  ----------------
  ansi-reset
  ansi-bold
  ansi-dim
  ansi-italic
  ansi-underline
  ansi-inverse
  ansi-hidden
  ansi-strikethrough
  ansi-black
  ansi-red
  ansi-green
  ansi-yellow
  ansi-blue
  ansi-magenta
  ansi-cyan
  ansi-white
  ansi-gray
  ansi-grey
  ansi-bgblack
  ansi-bgred
  ansi-bggreen
  ansi-bgyellow
  ansi-bgblue
  ansi-bgmagenta
  ansi-bgcyan
  ansi-bgwhite

That fucking ansi-red "package" has 1.3M weekly downloads.

I have to actually check to make sure he doesn't have packages like regexp-left-parenthesis, regexp-dot, etc.

View on HN

The code of ansi-red for those interested:

    var wrap = require('ansi-wrap');
    
    module.exports = function red(message) {
      return wrap(31, 39, message);
    };

And ansi-wrap:

    module.exports = function(a, b, msg) {
      return '\u001b['+ a + 'm' + msg + '\u001b[' + b + 'm';
    };

Now imagine those things inside a real utility that gets adopted by some popular package.

But from the average programmer's perspective this is clearly something they want. I see this general trend as a symptom of the inadequacy of JS to out-of-the-box address the tasks it's used for, which (as we note here) opens an outlet for spamming and security liabilities.

Having one package for all of these — that's okay and something people might want. Intentionally spreading it out to 26 "packages" — just no.

But the package that's generating all these numbers, handlebar-helpers, does precisely that. Sure, the spammer gets internet points, but those don't matter.

Security matters. Performance matters. Hackability/forkability matters. This kind of practice reduces security and auditability of systems, and makes projects harder to hack and fork.

From a security perspective what issues do you see besides auditability? It seems like the surface area for supply chain attacks is expanded needlessly by these types of shenanigans but I'm not sure how that translates to concrete impact to a project. I suppose resources required to scan and detect a package takeover are needlessly consumed but that's more upstream/centralized.

But I'm with you, this is ridiculous and auditability alone is reason enough to avoid it. Even if you were trying to make a case for composable packages this is absurd to the point that I wonder if it's self aware criticism of npm or an inside joke.

> does precisely that

Precisely what? That's not one self-contained package I said is okay.

No. What programmers want are solutions to problems.

Nobody is asking for the madness of having proper-sized packages split into 100 smaller packages with zero advantages and actually a few disadvantages (difficult to audit, impossible to fork). This is what is being criticised here.

It would be perfectly fine to have a single `terminal-utils` package that contained all of this. And no, handlebar-helpers doesn't count.

> I see this general trend as a symptom of the inadequacy of JS to out-of-the-box address the tasks it's used for, which (as we note here) opens an outlet for spamming and security liabilities.

Two wrongs don't make a right. Package authors should not spam, regardless of the issues with of the ecosystem or language.

I get the ridiculousness of those tiny packages. On the other hand I also hate to have my codebase bloated by some kitchen-sink "util" package of which I'll use about 0.1% functionality. (while, if I were really strict, I'd also have to audit and track the remaining 99.9% of the code.)

Tree-shaking can help at least keeping the build artefact small, but it doesn't help with the codebase during development.

Of course there is still a difference between fine-grained dependencies and things that shouldn't be dependencies in the first place.

There is a sane middle ground between tiny and bloated, though. I don't see how using a false dichotomy justifies the issues we're complaining about.

Especially when most of those packages are almost never used by themselves, and are instead part of a meta-package with dozens of dependencies.

ansi-red is not a difficiency of JS. It's just stupid. It the equivalent of a package called add2 and another called add3. No language I know of has that built in and if it did it would arguably be a bad sign

It's ridiculous and amusing at the same time. However, I blame the people depending on libraries such this; not the opportunists enabling them. They either don't know what they are doing (incompetence) or can't be bothered to do anything about it (indifference). The combination of can't be bothered and wouldn't know how to is what leads to people using shit like this.

In the defense of javascript, dead code elimination is kind of hard because it is such a dynamic/messy language and that kind of pushes people in the direction of ridiculously fine-grained modularization. Languages with an actual type system and compiler tend to produce artifacts that only include code that is actually needed. That requires dead code elimination that actually works. Beyond what comes with the browser, there isn't much of a standard library. That's for the same reason. You'd either end up shipping the whole thing on every website or depending on some convoluted tooling in an attempt to strip it down to what you are actually using. Minification is of course a thing but it usually boils down to more obfuscating than actually removing dead code.

My strategy is to generally avoid the whole ecosystem as much as I can. I've been using Kotlin-js lately. Great libraries, runs in a browser, reactive styled components using fritz-2, web compose, or if you really insist react. You still get exposed to some of the madness (like webpack breaking between minor releases) but mostly you are shielded from that.

I don't think dead code elimination would be the end-all to that problem either.

Yes, it reduces the space cost of having dead code in your build artefact, but it doesn't solve the problem of having dead code lying around during development.

The more code is in your dependencies, the more effort you have in auditing - even if it's only to ensure that code is actually dead - and doesn't cause any unexpected side effects or other behaviour in your program.

Spammer is a polite definition. His background is in marketing, the business he links brandscale[.]com is broken/abandoned. How long until we see these packages used as trojan horses? Or sold to third parties?

Let me balance the chi by linking to a prolific open source contributor who makes actually-good repos: https://github.com/sindresorhus?tab=repositories&q=&type=&la...

umm... I just randomly checked and this person also seem to have packages which are of few lines. for e.g. I checked `is-fn`:

    export default function isFunction(value) {
      const type = Object.prototype.toString.call(value);

      return type === '[object Function]' ||
       type === '[object GeneratorFunction]' ||
       type === '[object AsyncFunction]';
     }

This has 120k weekly downloads: https://www.npmjs.com/package/is-fn

It's a polyfill for a buggy function, so it's not just arbitrary.

The real question is why JS can't provide the answer to "isFunction" in a builtin method

It can: JavaScript has a `typeof` operator that can be used for this. If you read the readme for is-fn, it points out that the package is only useful for code that needs to run in certain older browsers that have a buggy implementation of `typeof`.

Oh, that's awful. It depends on ansi-wrap (another pretty much 1-liner package) with 2.6M weekly downloads.

Is there a site or code snippet where I can see which of the popular dependants was fooled into using this crap and is driving most of the downloads?

`npm ls <package_name>` or `yarn why <package_name>` is a good start for figuring out how a package ended up in your node_modules

Sure, I was looking for the opposite...which popular node package is pulling in ansi-wrap.

https://www.npmjs.com/browse/depended/ansi-wrap

Close, though sorted by popularity/downloads is really what I wanted...how to find where all the downloads are coming from.

I think that is sorted. If you go to the first result for `ansi-wrap` -> `ansi-gray` -> https://www.npmjs.com/package/fancy-log ("Log things, prefixed with a timestamp." by other creators: 2 398 259 weekly downloads)

Ah, yep...thanks. So we know where this particular bit of madness could be fixed.

It's very funny to me that these packages exist while one of his bigger projects (https://github.com/enquirer/enquirer) lists the following reason under "why use it":

> Lightweight - Only one dependency, the excellent ansi-colors by Brian Woodward.

Reply on news.ycombinator.com