NPM debug and chalk packages compromised

Which of these would you prefer to reimplement?

Debug, chalk, ansi-styles?

---

You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years.

I wouldn't use debug or ansi-styles. They're not even remotely close to being worth adding a dependency. Obviously none of them are trustworthy now though.

> You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years.

Okay, but you're not suggesting that a compression algorithm is the same scale as "is-arrayish". I don't think everyone should need to reimplement LZMA but installing a library to determine if a value is an array is bordering on satire.

I wouldn’t even use chalk. Altering terminal output is easy. But it should be used sparingly.

You're right. I only looked at the source for debug and ansi-styles. After looking at chalk it's insanity to add that as a dependency as well.

It's telling that we keep remembering xz to this day, while npm has these incidents on what feels like every single week.

A common refrain here seems to be that there is no good std lib, which makes sense for something like "chalk" (used for pretty printing?)

That being said, let's take color printing in terminal as an example. In any sane environment how complicated would that package have to be, and how much work would you expect it to take to maintain? To me the answer is "not much" and "basically never." There are pretty-print libraries for OS terminals written in compiled languages from 25 years ago that still work just fine.

So, what else is wrong with javascript dev where something as simple as coloring console text has 32 releases and 58 github contributors?

> So, what else is wrong with javascript dev where something as simple as coloring console text has 32 releases and 58 github contributors?

I see a new CLI graphics library on HN every other week.

https://github.com/fatih/color (Go) has 23 releases and 39 contributors.

https://github.com/BurntSushi/termcolor (Rust) has 173 contributors.

FWIW, is-arrayish is primarily an internal dependency. The author (Qix) depends on it for the packages that actually get used, liked color and error-ex.

But it's all one author.

They should ban Qix.

I mean, we're catching the ones on NPM. Who know how many xz's are hidden.

Skimming chalk's releases page, I did find some quick confirmation of what I expected: recent releases, at least breaking ones, are to do with keeping up with ecosystem changes:

https://github.com/chalk/chalk/releases

5.0: moving to ESM

4.0: dropping support for Node <10

3.0: indeed some substantive API and functionality changes

I got to 2.0 which added truecolor support. I was amused to note also that 3.0 and 2.0 come with splashy banner images in their GitHub releases

This is a pattern I've seen often with "connector" packages, e.g. "glue library X into framework Y". They get like 10 major versions just because they have to keep updating major versions of X and Y they are compatible with, or do some other ecosystem maintenance.

And yet it has 300M weekly downloads. I am fairly sure that most of these are not because it is a direct dependency of people's projects, but rather it is a dependency of a dependency of a dependency.

I think expo and eas-cli (the expo build service) is using chalk. Never understood what those cli need colors for what can be easily done with proper spacing and some symbols.

It might be an internal dependency for this author, but package.json is only for direct dependencies, right? github shows is-arrayish is a direct dependency of thousands of repos: https://github.com/search?q=%22is-arrayish%22+path%253Apacka...

Yes. And npm shows 1500 direct dependent packages. [1]

Vast majority are nothing. No stars, no downloads.

(IDK why. What I do know is that if you crack open the node_modules for any real project, is-arrayish will be there only because of one of the Qix packages.)

[1] https://www.npmjs.com/package/is-arrayish?activeTab=dependen...