7 ms·

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

by oefrha 5y ago

Ah, the infamous npm spammer jonschlinkert. This guy has even crazier packages like https://www.npmjs.com/package/ansi-red 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.

ratww 5y ago
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.
- dbreunig 5y ago
  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.
  - greggman3 5y ago
    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
  - oefrha 5y ago
    Having one package for all of these — that's okay and something people might want. Intentionally spreading it out to 26 "packages" — just no.
    - dbreunig 5y ago
      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.
      - ratww 5y ago
        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.
        brazzledazzle 5y ago
        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.
      - oefrha 5y ago
        > does precisely that Precisely what? That's not one self-contained package I said is okay.
  - deleted 5y ago
    [deleted]
  - ratww 5y ago
    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.
    - xg15 5y ago
      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.
      - ratww 5y ago
        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.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
tyingq 5y ago
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?
- phist_mcgee 5y ago
  `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
  - tyingq 5y ago
    Sure, I was looking for the opposite...which popular node package is pulling in ansi-wrap.
    - jcuenod 5y ago
      https://www.npmjs.com/browse/depended/ansi-wrap https://www.npmjs.com/browse/depended/ansi-wrap
      - tyingq 5y ago
        Close, though sorted by popularity/downloads is really what I wanted...how to find where all the downloads are coming from.
      - jcuenod 5y ago
        I think that is sorted. If you go to the first result for `ansi-wrap` -> `ansi-gray` -> https://www.npmjs.com/package/fancy-log https://www.npmjs.com/package/fancy-log ("Log things, prefixed with a timestamp." by other creators: 2 398 259 weekly downloads)
        tyingq 5y ago
        Ah, yep...thanks. So we know where this particular bit of madness could be fixed.
jillesvangurp 5y ago
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.
- xg15 5y ago
  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.
beaconstudios 5y ago
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=&language=&sort=stargazers https://github.com/sindresorhus?tab=repositories&q=&type=&la...
- avinassh 5y ago
  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 https://www.npmjs.com/package/is-fn
  - beaconstudios 5y ago
    It's a polyfill for a buggy function, so it's not just arbitrary.
  - raverbashing 5y ago
    The real question is why JS can't provide the answer to "isFunction" in a builtin method
    - datagram 5y ago
      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`.
zsims 5y ago
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?
fspoettel 5y ago
It's very funny to me that these packages exist while one of his bigger projects (https://github.com/enquirer/enquirer https://github.com/enquirer/enquirer) lists the following reason under "why use it": > Lightweight - Only one dependency, the excellent ansi-colors by Brian Woodward.

by oefrha 5y ago

ratww 5y ago

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.

dbreunig 5y ago
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.
- greggman3 5y ago
  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
- oefrha 5y ago
  Having one package for all of these — that's okay and something people might want. Intentionally spreading it out to 26 "packages" — just no.
  - dbreunig 5y ago
    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.
    - ratww 5y ago
      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.
      - brazzledazzle 5y ago
        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.
    - oefrha 5y ago
      > does precisely that Precisely what? That's not one self-contained package I said is okay.
- deleted 5y ago
  [deleted]
- ratww 5y ago
  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.
  - xg15 5y ago
    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.
    - ratww 5y ago
      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.
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

tyingq 5y ago

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?

phist_mcgee 5y ago
`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
- tyingq 5y ago
  Sure, I was looking for the opposite...which popular node package is pulling in ansi-wrap.
  - jcuenod 5y ago
    https://www.npmjs.com/browse/depended/ansi-wrap https://www.npmjs.com/browse/depended/ansi-wrap
    - tyingq 5y ago
      Close, though sorted by popularity/downloads is really what I wanted...how to find where all the downloads are coming from.
    - jcuenod 5y ago
      I think that is sorted. If you go to the first result for `ansi-wrap` -> `ansi-gray` -> https://www.npmjs.com/package/fancy-log https://www.npmjs.com/package/fancy-log ("Log things, prefixed with a timestamp." by other creators: 2 398 259 weekly downloads)
      - tyingq 5y ago
        Ah, yep...thanks. So we know where this particular bit of madness could be fixed.

jillesvangurp 5y ago

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.

xg15 5y ago
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.

beaconstudios 5y ago

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=&language=&sort=stargazers https://github.com/sindresorhus?tab=repositories&q=&type=&la...

avinassh 5y ago
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 https://www.npmjs.com/package/is-fn
- beaconstudios 5y ago
  It's a polyfill for a buggy function, so it's not just arbitrary.
- raverbashing 5y ago
  The real question is why JS can't provide the answer to "isFunction" in a builtin method
  - datagram 5y ago
    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`.

zsims 5y ago

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?

fspoettel 5y ago

It's very funny to me that these packages exist while one of his bigger projects (https://github.com/enquirer/enquirer https://github.com/enquirer/enquirer) lists the following reason under "why use it": > Lightweight - Only one dependency, the excellent ansi-colors by Brian Woodward.