NPM debug and chalk packages compromised

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

You typically don't. But a lot of packages that you do install depend on smaller stuff like this under the hood (not necessarily good and obviously better handled with bespoke code in the package, but is is what it is).

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.

Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package.

A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but still is tricky and not widespread.)

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

This is spreading everywhere, Rust, Python, ...

This conversation been a thing since at least the leftpad event. It's just how the js ecosystem works it seems. The default library is too small perhaps?

Extreme aversion to NIH syndrome, perhaps? I agree that it's weird. Sure, don't try to roll your own crypto library but the amount of `require('left-pad')` in the wild is egregious.

Then the question becomes, why do developers of larger libraries import someone else's module for every little trivial thing?

This is the answer IMO. The number of targets and noise would be a lot less if JS had a decent stdlib or if we had access to a better language in the browser.

I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.

It's easier to find something frustrating in large code changes than in single line imports, even if the effective code being run is the same -- the PR review looks cleaner and safer to just import something that seems "trusted".

I'm not saying it is safer, just to the tired grug brain it can feel safer.

Not Java, thankfully! Libraries containing 1-2 trivial classes do exist, but they're an exception rather than a rule. Might be that the process of publishing to Maven Central is just convoluted enough to deter the kinds of people who would publish such libraries.

But why can’t we have a good library instead of those mini thingies?

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.

Doesn’t the bundler already do tree shaking? Optimizing via dependency listing is very wrong.

Because they don't have the slightest clue what they're doing.

> 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.

Because you have to figure out what should be in it, and coordinate the distribution. It's not like there's a reference implementation of JavaScript maintained by a well-known team that you consciously install everywhere that you need it.

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

Because a mini thing can be written in mini time by a mini number of people

To be fair, this is not a problem with the web itself, but with the Node ecosystem.

It's perfectly possible to build web apps without relying on npm at all, or by being very selective and conservative about the packages you choose as your direct and transitive dependencies. If not by reviewing every line of code, then certainly by vendoring them.

Yes, this is more inconvenient and labor intensive, but the alternative is far riskier and worse for users.

The problem is with web developers themselves, who are often lazy, and prioritize their own development experience over their users'.

Worth mentioning...

https://jsr.io/@std

npmjs is the stdlib, or what emerged from it.

It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative also specified concrete modules such as the interfaces for node.js/express.js HTTP "middlewares" you can plug as routes and for things like auth handlers (JSGI itself was inspired by Ruby's easy REST DSL).

The reason for is-array, left-pad, etc. is that people wanted to write idiomatic code rather than use idiosyncratic JS typechecking code everywhere and use other's people packages as good citizens in a quid pro quo way.

[1]: https://wiki.commonjs.org/wiki/CommonJS

Edit: the people crying for an "authority" to just impose a stdlib fail to understand that the JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations; this concept seems lost on TypeScripters who need big daddy MS or other monopolist to sort it all out for them

Also because Java, .NET, etc. all have very expansive standard libraries. You don't need to import most stuff, as it's already built-in.

Tree shaking is less than reliable... for it to work well, all the dependencies need to be TS/ESModule imports/exports and even then may not shake out properly.

It helps, but not as much as judicious imports. I've been using Deno more for my personal projects which does have a pretty good @std library, though I do think they should keep methods that simply pass through to the Deno runtime, and should probably support working in Node and Bun as well.

Very true... I'm more experienced with .Net, but usually when you bring in something, it's much more of a compositional library or framework for doing something... like a testing harness (XUnit), web framework (FastEndpoints), etc. No so much in terms of basic utilities, where the std library and extensions for LINQ cover a lot of ground, even if you aren't using LINQ expressions themselves.

I mean, Apache Commons are still widely used. But it's just a handful of libraries maintaned by one organisation.

I just never got the argument against including things like the sort of text formatting tools and such that people always import libraries for. It’s not like an embedded system for mission-critical realtime applications where most functions people write for it get formal proofs — it’s freaking javascript. Sure it’s become a serious tool used for serious tasks for some reason, but come on.

For C++ there are Boost, Folly, Absl, several more large libraries with reputable orgs behind them. I'm surprised someone doesn't make a big npm lib like that.

Not hating on the author but I doubt similar compromise would happen to Facebook or Google owned package.

The difference, at least in languages like Java or Python, is that there is a pretty strong "standard" library that ships with the language, and which one can assume will be kept up-to-date. It is very hard to assume that for NPM or Rust or any other crowd-sourced library system.

> doesn't make a big npm lib like that.

People have done, but the ecosystem has already engrossed around the current status quo and it's very hard to get rid of habits.

example https://github.com/stdlib-js/stdlib

Or the language is too braindead. `is-arrayish` should not even have to be a thing.

I'm often surprised at the number of JS experts who struggle with the basics of the browser API. Instead of reasoning through the problem, many will reach for a framework or library.

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.

It's not that either.

There are a handful of important packages that are controlled by people who have consulting / commercial interests in OSS activity. These people have an incentive to inflate download numbers.

There could be a collective push to move off these deps, but it takes effort and nobody has a strong incentive to be the first

"JS people" don't, but certain key dependencies do, and there are social / OSS-political reasons why.

Why do "Java people" depend on lowrie's itext? Remember the leftpad-esque incident he initiated in 2015?

I can provide you with some missing background as I was a prior full time JavaScript/TypeScript developer for 15 years.

Most people writing JavaScript code for employment cannot really program. It is not a result of intellectual impairment, but appears to be more a training and cultural deficit in the work force. The result is extreme anxiety at the mere idea of writing original code, even when trivial in size and scope. The responses vary but often take the form of reused cliches of which some don't even directly apply.

What's weird about this is that it is mostly limited to the employed workforce. Developers who are self-taught or spend as much time writing personal code on side projects don't have this anxiety. This is weird because the resulting hobby projects tend to be substantially more durable than products funded by employment that are otherwise better tested by paid QA staff.

As a proof ask any JavaScript team at your employment to build their next project without a large framework and just observe how they respond both verbally and non-verbally.

Same reason they do in rust.

The rust docs, a static site generator, pull in over 700 packages.

Because it’s trivial and easy

Not just a stdlib, lack of an SDK as well. Both Deno and Bun have decided to ship with tooling included, which cuts down on dev dependency bloat.

> The responses vary but often take the form of reused cliches of which some don't even directly apply.

"It has been tested by a 1000 people before me"

"What if there is an upstream optimisation?"

"I'm just here to focus on Business Problems™"

"It reduces cognitive load"

---

Whilst I think you are exaggerating, I do recognise this phenomenon. For me, it was during the pandemic when I had to train / support a lot of bootcamp grads and new entrants to the career. They were anxious to perform in their new career and interpreted that as shipping tickets as fast as possible.

These developers were not dumb but they had... like, no drive at all to engage with problems. Most programmers should enjoy problems, not develop a kind of bad feeling behind the eyes, or a tightness in their chest. But for these folks, a problem was a threat, of a bad status update at their daily Scrum.

Dependencies are a socially condoned shortcut to that. You can use a library and look like a sensible and pragmatic engineer. When everyone around you appears to accept this as the norm, it's too easy to just go with the flow.

I think it is a change in the psychological demographic too. This will sound fanciful. But tech used to select for very independent, stubborn, disagreeable people. Now, agreeableness is king. And what is more agreeable than using dependencies?

The two I hear the most are:

reinventing the wheel

some comparison to assembly

Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.

But then you depend on Microsoft for everything. I prefer python where it's battery Included but you depend on a foundation

Given how fat a modern website is, I am not sure that a kitchen sink library would change much. It could actually improve things because there would be fewer redundant libraries for basic functionality.

Say there is neoleftpad and megaleftpad - both could see widespread adoption, so you are transitively dependent on both.

> Most people writing JavaScript code for employment cannot really program.

> As a proof ask any JavaScript team at your employment to build their next project without a large framework and just observe how they respond both verbally and non-verbally.

With an assumption like that, I bet the answer is mostly the same if you ask any Java/Python dev for example — build your next microservice/API without Spring or DRF/Flask.

Even though I only clock at about 5YOE, I'm really tired of hearing these terrible takes since I've met plentiful share of non-JS backend folks for example, who have no idea about basic API design, design patterns or even how to properly use the same framework they use for every single project.

I don't quite know how to put this thought together yet, but I've noticed that no one quite hates programming more than this class of programmers. It's like playing on a football team with people who hate football.

A key phrase that comes up is "this is a solved problem." So what? You should want to solve it yourself, too. It's the PM's job to tell us not to.

Not sure about “agreeableness” but I can see group think and disagreeableness to anything that falls outside of the group think. Cargo cult coding isn’t a new thing but the demographic shift you note is real. But is that not just the commodification of programming labor?

Not my experience at all. It's more like a) JS devs view NPM packages as a mark of pride and so they try to make as many as possible (there are people proud of maintaining hundreds of packages, which is obviously dumb), and b) people are lazy and will take a ready-made solution if it's available, and c) there are a lot of JavaScript developers.

The main reasons you don't see this in other languages is they don't have so many developers, and their packaging ecosystems are generally waaay higher friction. Rust is just as easy, but way higher skill level. Python is... not awful but it's definitely still a pain to publish packages for. C++, yeah why even bother.

If Python ever official adopts uv and we get a nice `uv publish` command then you will absolutely see the same thing there.

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?

There's also the option of including that standard lib with the runtime.

Hasn't .net been open-source for like 10 years?

Node is pretty much everywhere regarding JavaScript cli and web apps (server side). As for the web it’s hard to argue for a slim library when most sites are dumping huge analytics bundle on us.

At this point, it’s just status-quo and lazyness

Rust is an interesting case to me.

There are certainly a lot of libraries on crates.io, but I’ve noticed more projects in that ecosystem are willing to push back and resist importing unproven crates for smaller tasks. Most imported crates seem to me to be for bigger functionality that would be otherwise tedious to maintain, not something like “is this variable an array”.

(Note that I’m not saying Rust and Cargo are completely immune to the issue here)

I agree that it doesn't need to exist, but as far as I can tell, almost no one depends on it directly. The only person using it is the author, who uses it in some other small libraries, which are then used in a larger, nontrivial library.

I just created a Next.js app, saw that `is-arrayish` was in my node_modules, and tried to figure out how it got there and why. Here's the chain of dependencies:

next > sharp > color > color-string > simple-swizzle > is-arrayish

`next` uses `sharp` for image optimization. Seems reasonable.

`sharp` uses `color` (https://www.npmjs.com/package/color) to convert and manipulate color strings. Again, that seems reasonable. This package is maintained by Qix-.

Everything else in the chain (color-string > simple-swizzle > is-arrayish) is also maintained by Qix-. It's obnoxious to me that he feels it is necessary to have 80 different packages, but it would also be a substantial amount of effort for the other parties to stop relying on Qix-'s stuff entirely.

Because "look at how many open source packages I maintain!"

At a time small JS libraries were desired, and good library marketing approach, but nowadays simple sites ship megabytes of without a care.

In particular this developer is symptomatic of the problem of the NPM ecosystem and I've used him multiple times as an example of what not to do.

Especially with the MDN, an amazing resource.

This is because you cannot easily remove problematic stuff from the browser. It's actively being used by someone, so the vendors keep it, so it continues to be used. The process takes decades, literally.

On the server side, of course, you can do whatever you like, see Node / Deno / Bun. But the code bundle size plays a minor role there.

> 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.

The JS ecosystem values quantity over quality, for some bizarre reason.

> JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations

It's not unique in this sense, yet others manage to provide a lot more in their stdlib.

It's not that you need a "big daddy". It's that the ecosystem needs a community that actually cares about shit like this vulnerability.

It is, but it's still firmly controlled by Microsoft, particularly when it comes to ecosystem evolution. Some people find that uncomfortable even if the source is open - legal right to fork is one thing, technical ability to do so and maintain said fork is another.

> They were anxious to perform in their new career and interpreted that as shipping tickets as fast as possible. [...].. they had like, no drive at all to engage with problems

To be honest, I think these programmers understood their jobs perfectly here. Their bosses view programmers as commodities, are not concerned with robustness, maintainability, or technical merit - they want a crank they can turn that spits out features.

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.

But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import, that you can track and version and pay attention to.

Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar.

Why instead do people in the javascript ecosystem insist on separating every function into it's own library that STILL has to import helper libraries? Why do they insist on making imports fractally complex for zero gain?

Sometimes it's not someone else's module, it's their own. They break up the big library into reusable components, and publish them all separately. Essentially taking DRY to an extreme: don't have private functions, make all your implementation details part of the public API & reuse them across projects.

That’s a tactic shitty maintainers do: write N dubious modules that no sane person would install. Write one or two valuable modules that import those N dubious modules.

They should ban Qix.

Yes this is the fundamental problem.

It started with browsers giving you basically nothing. Someone had to invent jQuery 20 years ago for sensible DOM manipulation.

Somehow this ethos permeated into Node which also basically gives you nothing. Not even fundamental things like a router or db drivers which is why everyone is using Express, Fastify, etc. Bun and Deno are fixing this.

I didn't used to be. It's just become less trendy to import a big giant Lodash, Underscore, Sugar, or even jQuery.

Originally I think it was to avoid the applet experience of downloading a large util.jar or etc. (Not that most js devs really care.) However, I suspect the motivation is often social status on GitHub & their resume.

It seems in some large businesses code ownership is an issue too.

If you NPM import that's now part of your SCA/SBOM/CI to monitor and keep secure.

If you write code, it's now your problem to secure and manage.

If Javascript people were bad programmers, we wouldn't see two new frontend frameworks per year. Many of them are ambitious projects that must have had thousands of hours put in by people who know the language well.

The observation is real however. But every culture develops its own quirks and ideas, and for some reason this has just become a fundamental part of Javascript's. It's hard to know why after the fact, but perhaps it could spark the interest of sociologists who can enlighten us.

At least historically it used to be the case that you don't ever want to use the browser API directly for compatibility reasons but always through some library that will be a do-nothing-wrapper in some cases but do a bunch of weird stuff for older browsers. And traditions are sticky.

And a mini thing can be switched to another 'mini' package easy enough if the current package decides to do something dumb.

If your mega package decides to drop something you need you pretty much have to follow.

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

Glad to see someone else identify the anxiety at the root of the culture.

After an npm incident in 2020 I wrote up my thoughts. I argue that this anxiety is actually somewhat unique to JS which is why we don't see a similar culture in other languages ecosystems

https://crabmusket.net/java-scripts-ecosystem-is-uniquely-pa...

Basically, the sources of paranoia in the ecosystem are

1. Weak dynamic typing

2. Runtime (browser engineers) diversity and compatibility issues

3. Bundle size (the "physics" of code on a website)

In combination these three things have made JS's ecosystem really psychologically reliant on other people's code.

Bundle size optimisation. See my comment upthread for more detailed explanation. Bundle size is one of the historical factors that makes JS ecosystem a unique culture, and I'd argue uniquely paranoid.

I agree with you, but I'd ask- what other language needs to distribute to an unknown runtime environment over the network?

If it's the browser's job to implement the standard library, how do you ensure that all browsers do this in a compliant and timely fashion? And if not, how do you optimise code-on-demand delivery over the internet?

I don't deny there are/could be solutions to this. But historically JS devs have wrestled with these issues as best they can and that has shaped what we see today.

That is exactly what happens today. JS has a standard library. It's just not evenly distributed.

How is this different than npm? It looks like a bunch of third-party packages, just prefixed with std.

And never ever be able to correct your past mistakes, because some sites might still be using them? The web platform is no .NET runtime you can just update.

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.

There's a reason you don't see two frameworks every year in another language. Being a good programmer is recognizing when a problem is solved and actually contributing to the solution instead of recreating it. Coding a new system can be done really quickly as you're mostly focusing on the happy path. The real work is ironing out bugs and optimizing the performance.

> If your mega package decides to drop something you need you pretty much have to follow.

Or you can code it in. Mega packages can be very stable. Think SDL, ffmpeg, ImageMagick, Freetype...There's usually a good justification for dropping something alongside a wide deprecation windows. You don't just wake up and see the project gone. It's not like the escape codes for the unix terminal are going to change overnight.

> what other language needs to distribute to an unknown runtime environment over the network?

What is this unknown runtime environment? Even during the browser war, there was just an handful of browsers. And IE was the only major outlier. Checking the existence of features and polyfilling is not that complicated.

And most time, the browser is already downloading lot of images and other resources. Arguing about bundle size is very hypocritical of developers that won't blink at adding 17 analytics modules.

It's not, and a third of them are tagged as unstable. JSR also still seems to not encourage proper versioning.

They are separate packages, curated by the Deno team[1]. The interfaces are pretty consistent and useful.

1. https://github.com/denoland/std

They are published as separate packages, but managed in the same repo by the Deno team. Versioning works fine with JSR.

A fully-formed standard library doesn't spring into existence in a day.

> Checking the existence of features and polyfilling is not that complicated.

Judging by what we see in the world, most developers don't agree with you. And neither do I. A handful of browsers, multiplied by many versions per browser in the wild (before evergreen browsers like Chrome became widespread, but even today with e.g. Safari, or enterprise users), multiplied by a sprawling API surface (dare I say it, a standard library) is not trivial. And that's not even considering browser bugs and regressions.

> very hypocritical of developers that won't blink

Not a great argument, as developers don't necessarily get to choose how to add analytics, and plenty of them try to push back against doing so.

Also, the cost of parsing and JIT'ing JS code is byte-for-byte different to the cost of decoding an image.

> TypeScripters who need big daddy MS or other monopolist to sort it all out for them

What is this crap statement?

So you want type-checking because it helps you catch a class of errors in an automated way, and suddenly you have a daddy complex and like monopolies?

Claiming this says a lot more about you than people who use TypeScript.

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.

> Judging by what we see in the world, most developers don't agree with you. And neither do I.

From my POV, most developers just test on the most popular browser (and the latest version of that) without checking if the API is standard or its changelog. Or they do dev on the most powerful laptop while the rest of the world is still on 8gb, FHD screen with integrated gpu.

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.

One of the most bizarre attacks on typescript I've seen lol.

They seem pretty cautious with that unstable flag too.

UUID v7 for example is unstable and one would be pretty confident in that not changing at this stage.

Many unstable functions have less churn than a lot of other “stable” packages. It’s a standard library so it’s the right place to measure twice before cementing it forever.

Explain browser defaults to non JavaScript people is kind of eye opening I've found

A batteries included standard lib included with the runtime is one approach. Yes, you would know upfront the version which the browser implements. From there you could dynamically load a polyfill or prompt the user to upgrade.

Alternatively, because there are now (often ridiculous) build systems and compilation steps, we might expect similar behavior to other compiled binaries. Instead we get the worst of both worlds.

Yes, JS as it is is some kind of standard, but at a certain point we might ask, "Why not throw out the bad designs and start from scratch?" If it takes ten years to sunset the garbage and offer a compatibility shim, that's fine. All the more reason to start now.

A purely compiled WASM approach with first class DOM access or a clean scripting language with a versioned standard lib, either option would be better than the status quo.

> A purely compiled WASM approach

I would love to see if a browser could like... "disaggregate" itself into WASM modules. E.g. why couldn't new JS standards be implemented in WASM and hot loaded into the browser itself from a trusted distributor when necessary?

Missing CSS Level 5 selectors? Browser goes and grabs the reference implementation from the W3C.

Low-level implementations could replace these for the browsers with the most demanding performance goals, but "everyone else" could benefit from at least remaining spec compatible?

(I guess this begs the question of "what's the API that these WASM modules all have to conform to" but I dunno, I find it an interesting thought.)

But most of the documentation and tooling is around visual studio and azure

If you want type safety there are any number of better languages out there compiling to JavaScript. The entire point of JS is that's a portable good enough dynamic scripting language, not a freaking mess changing all the time.

Yes, that would be a compelling change. Like a language agnostic HotJava platform. We're overdue for a more coherent approach, from the bottom up.

I think you are right. Those feature factory teams were the ones hiring as fast as they could; they didn't need to filter on programming fundamentals; and they could exploit the anxiety of junior developers who sensed the market was becoming competitive.

> how do you ensure that all browsers do this in a compliant and timely fashion?

The ecosystem somehow manages to figure this out for things like fancy CSS gradients...

Web browsers update far more often than .NET runtime, if anything. And .NET still supports a lot of deprecated stuff going all the way back to 1.0; so does Java (old-style collections, for example).

Also, JavaScript is a shining example of "never ever be able to correct your past mistakes" already, so it's not like this is something new for the web.

JS standard library is missing very basic things like maps with value semantics for keys that aren't primitives.

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...