It’s a much better choice to just copy the source code and possibly license into your own code to just eliminate the overhead.

It’s not like any of these packages depend on being updated for security reasons or anything.

The thinking was as follows: Of course you could just copy the code, but then that increases LOC in my codebase that I'm responsible for. More code is more work. Lines in a dependency are the responsibility of someone else. If there's a bug, even in a small function, the community can identify it and fix it. I can get new features I might not have known I needed. I can benefit from all of these fixes indefinitely into the future without ever having to have any mental overhead about that code. So can everyone else; it's good to maximize code reuse.

I don't think I've ever used something that could be an obvious one-liner like `isOdd` but for lots of only slightly more complex stuff like left-pad, email format validation, GPS coordinate math functions -- all stuff that's really less than 30 lines -- it was really nice to just not have to think about the implementation details of that and get back to solving your problem. I could have reviewed the code or written it myself but it's just more work when remaining at a high level `leftPad()` call let's me stay focused on my original task.

That said, I've since realized I was wrong of course. Trying to maintain projects that haven't been touched in more than a year led to hours of fixing dependency issues. We switched to using dependabot, which is better, but just makes it obvious how much work it actually is to keep dependencies up to date week-to-week. Then there's all of the security issues. These days, for small packages, I advocate for reviewing the code from these packages, ensuring we understand it, and then copying it in directly with a comment for attribution. We generally try to keep dependencies low; still more than in other languages but at least some thoughtfulness about whether it's "worth it". I think a lot of the community has shifted similarly, but there's still a lot of older projects with older dependencies.

Once your company is owned by a supply chain attack or by an RCE in one of your dependencies, you will learn that you are in-fact very much responsible for the code in your external dependencies.

He’s a prolific open source author that traditionally had a lot of modularization in his packages—though I think he has started to move away from it recently. He talks about it here: https://blog.sindresorhus.com/small-focused-modules-9238d977...

Most projects will include at least one package by him in the dependency tree.

I vastly prefer to use libraries with 0 dependencies but I never quite manage it, so I end up with the same problems as everyone else.

It's an unpopular opinion for some silly reason. It's like when Guava or Apache Commons was included on every single Java project in the 2010s. "It's just so much easier to use a well-tested library". That line of thinking is what got us here.

The individual functions are installable separately from NPM, and lodash-es should tree-shake quite well, but I do know what you mean about it dragging in its internal dependencies so you end up with a 15kb of lodash code for a single thing. I probably wouldn't love to use it client-side on an ordinary website, were I to make one.

This might be controversial, but I think it has to do with less experienced developers, beginners, who doesn't know how to find out via "pure code" if a number is even or not, or even if something is a number (IIRC, there is an isNumber package out there as well).

I see this in other languages as well, but not in a "JavaScript scale", but that could probably just mean that the language's availability and popularity decides the number of "stupid packages."

I haven't worked with anyone for years that doesn't start troubleshooting an issue by reaching for a random dependency. They just don't even bother learning Javascript or the Web APIs or CSS anymore. Without a solid base of fundamentals every trivial problem seems insurmountable so they just don't even try.

This minority makes money out of their popularity in the NPM ecosystem. Having 1000 NPM packages is better for your reputation than having 100. And having all 1000 packages with lots of weekly downloads is better than having just a portion of that.

But how do they achieve that? Well, they have 1000 NPM packages, so each one depends on 5 to 10, that then depends on a few handful more. You have packages for checking if an HTTP status is a certain number, you have packages that have colors as constants, you have is-even, is-odd and so on. All that exists to maintain that closed ecosystem.

So out of the 1000 they basically have 20 useful tools and 980 garbage packages that exist only to maintain their own ecosystem.

Most people isn't using is-even or is-odd directly. They imported some other packages that are quite useful, but often need 10-20 sub-dependencies. Another interesting thing is that those shitty packages aren't really that important in applications. They're often used in build tools, CI and testing, tools for making CLI tools, and the sort.

The crazy thing is that a lot of people using is-even/is-odd aren't really "noobs": they're probably experienced developers that said "fuck it, I'll use some random tool from the web" when facing some random a problem.

That said, it still leaves a sour taste as this effectively implies that a certain set of JS developers is very happy to abuse their (maybe initially rightfully earned) prestige to gain even more prestige while leaving behind a mess for the whole ecosystem. I don't understand why this is tolerated. The Node community needs to have a serious discussion about why certain packages are allowed to spread garbage, create forks of the relevant packages that rip out "is-even" etc. and then eventually converge to these forks. But to this day, I don't see the community taking this problem seriously enough.

Now, supply chain attacks and "too many dependencies" are a potential issue for every language with dependency management (see also log4j, etc.), but no other ecosystem seems to be have such a high frequency of issues and (widely used) "is-even" packages are simply not a thing in any other mainstream language (some languages, like Swift, include similar functionality in the standard library, which is totally fair).

For every person calling it out like we're doing here, there are ten others praising maintainers able to whip ten semi-useless packages per week.

It's not just random maintainers making small packages. The core infrastructure of Javascript is in it. Babel is made of hundreds of packages, which all live on the same repository (because of course the maintainers don't want the hassle of maintaining multiple things). Some of those packages don't even have anything of importance in it, just metadata, a couple flags and some boilerplate [1]. The package is just a way of organizing code. Webpack, ESLint and others aren't exactly better.

EDIT: And of course I got downvoted :)

[1] https://github.com/babel/babel/blob/main/packages/babel-plug...

> The core infrastructure of Javascript is in it. Babel[...]

Babel is not core JS infrastructure. It may be close to fundamental to the modern NodeJS development experience, but JS exists happily (and capably) without any of that stuff (including package.json, for that matter).

I don't really despise anyone in Babel, though, I'm only criticising their packaging method. Babel isn't doing the million-packages thing to gain popularity.

Should we treat them as spammers and polluters, then? Because if what you describe is true, that deserves to be called out and mowed to the ground.

It is more akin to SEO spamming than black market spamming, though. They're polluting NPM in the same way SEO farms spam Google. It makes life difficult for everyone, but it's still a gray area in terms of legitimacy. Which is why nobody really talks about it.

If incentives were aligned differently, different results might have resulted. Probably with different externalities (or unintended consequences).

[0]: https://en.wikipedia.org/wiki/Tragedy_of_the_commons?wprov=s...

IMO, that's even worse, because that means that a lot of people are using stupid and vulnerable packages without knowing it.

I wish there was some sort of better control over the NPM directory, where someone could block/downvote (or whatever) packages that doesn't deserve to live. How this would - or should - work in practice, I have no idea, but it's just getting scarier by the day to import a package in your application.

If we ban those, we'd have to ban Babel and Webpack too... Oh now, wait a minute, now that actually sounds interesting...

What if we focused on fixing all the problems, and not just retreating thinking that "we can't solve this problem, because there are so many other problems related to it"?

Your thinking is literally the definition of the problem.

Maybe you could argue other for other reasons to use these packages.

1. search for a package that does X

2. scan the search result and find the package that really does X

3. learn to use the package's API

4. import the package in the code

5. use it

Isn't it much easier to just copy-paste code from stackoverflow? There's also a good chance that the you can get some very good explanation and interesting discussion around the implementation there.

There's also Github Copilot, which pretty much replaced almost my entire usage of Stack Overflow.

But the thing is that with a rando package is that one doesn't have to review the code. Sure, the code is also coming from somewhere else. Sure, it might never get updated. Sure it might be full of bugs. Sure, it might be more dangerous than copying from StackOverflow. But out of sight, out of mind.

In the end the overuse of packages isn't about saving time or "doing the best for business" or "ensuring that the code is maintained by someone else". It's purely about covering our asses.

Most times I get the urge to pull in a rando package I find I really only need a few things it does. I check it out. Read it. Write my own.

I almost never need "all the things" outside the situations where I am using a big framework. So reading it, getting inspired / ideas from someone who did the thing and then I write a much more narrow focused version for myself.

This can be complicated. Depending on another package is usually very safe, at least as safe as "dynamic linking", but including code in your own source tree needs licenses to be compatible. Even then, you might have to change your license to "BSD-3-Clause + ISC" or similar composite and you will get complaints from users.

TL;DR "SEO" spam to market ones own nodejs expertise, would not be out of the question

Compared to that, left-pad is rocket science

An entire module for just `return value !== value;`

(Not supporting a culture of taking a dependency for this sort of thing, though)

                isNaN   Number.isNaN
                -----   ------------
    {}           true          false
    [true]       true          false
    undefined    true          false
    "{}"         true          false

It actually works like this: Author X develops `iseven`, `isodd`, etc. No one really downloads such packages. Author X then develops `importantPackage` which does do something useful developers out here download. The thing is `importantPackage` relies on `iseven` and `isodd`. Now `iseven`, `isodd` are downloaded alongside `importantPackage`. Profit.

My point is, we should recognize certain NPM authors as toxic, but I guess "freedom of speech/code" stops us from doing so. Example of such an author: https://github.com/jonschlinkert/

I consider 'iseven' and 'isodd' to be signs that Javascript is a hellaciously engineered piece of crap that should be avoided at all costs. They're popular because Javascript is garbage.

  let isEven = theNumber % 2 == 0;

Because I firmly believe that crap like this happens because the language itself is very, very dumb.

However, some variation on n%2==0 is idiomatic in a large number of languages, both modern and old [0].

This includes Lua, Java, Python, Scala, Perl, PHP, Swift, and many others.

It is true that there are numerous languages with built in convenience methods in their standard libraries, but that does not by itself mean that n%2==0 is problematic and certainly this idiom is deeply entrenched.

There is nothing preventing a developer using those languages from wrapping this in a function, and indeed this is probably a good idea if it’s something you find yourself using repeatedly throughout your code base, just like any other often-repeated code snippets.

- [0] https://www.rosettacode.org/wiki/Even_or_odd

It’s like doing a for(i=0; i<items.length:i++) { e=items[i] } to iterate over each element instead of something like foreach, or a lambda.

How is that for loop not expressing what it means? for is used to iterate over something. There are legitimate reasons to choose for even when forEach is available.

Does this not express what I mean?

  if (amount > balance)
    return “insufficient_funds”;

Abstraction can help simplify complex problems, and that’s what it is good at. But when literally everything is abstracted away, it becomes harder to reason about what the program is doing without also learning about what the particular abstraction does (e.g. implicitly handling negative numbers, etc).

A well implemented standard library can be a joy to use, and some people choose languages for this reason. Some languages very intentionally provide a very lightweight standard library, and that’s just fine. All of this shouldn’t absolve the developer from understanding some of the very basic constructs of the language they choose - a lack of which will lead to bugs and vulnerabilities.

If I choose JavaScript (or it’s chosen for me), it behooves me to understand the basics vs. farming this out to some node package that just made my app harder to reason about and vulnerable to supply chain attacks for essentially no value.

jbverschoor said (edited for brevity):

> Yes. But you’re not expressing what you mean.

> It’s like doing a

  > for(i=0; i<items.length:i++)
  >   { e=items[i] }

haswell replied:

> How is that for loop not expressing what it means?

It's true that the for loop is accomplishing the goal, but it is specifically running through the elements from 0 to length.

But sometimes what you want to do is, for example, apply a function to every element, and the fact that they are in a structure indexed from 0 to N-1 is not relevant. Your intent is to do a thing for every element, not to run down a list doing the thing.

There is a difference in intent, and using foreach instead of a for loop quite specifically expresses that.

Small examples like this are never convincing, but there really is a difference between "Run down this list" and "do this thing for every element". The output is the same, but the intent is different, and expressing that intent is important in larger projects.

It may be true that running from 0…length is not the most important part, but it may also be true that I need more flexibility and control while iterating, and may still choose to use for as a result.

But I think we’re getting a bit off track (and I helped get us here…).

jbverschoor‘s comment was a followup about the expressiveness of the modulo operator vs built-in convenience methods.

At least in the case of JavaScript, there isn’t an isEven available. If it was, an argument could be made that using it is more expressive. Since it doesn’t, the argument can be made that the most expressive option is the idiomatic one. Certain code fragments become idiomatic for a reason.

I interpreted the comments about for and the perceived lack of expressiveness in using it against this backdrop, and my point was just that for still has a time and a place. It may be that jbverschoor recognizes this, but I think the comparison doesn’t quite help when examining the use of modulo.

Going back to the original, there is a difference between "isEven(n)" and "0==n%2". Sometimes (and this is definitely true in some code I write) there is a conceptual difference between asking if something is even, versus asking if it leaves a remainder of 0 upon division by 2. Yes, they can be proven to be equivalent, but the underlying intent is different.

BTW, I agree entirely that in these cases it's really mostly pointless, but the principle carries over to larger examples. Trying to see that there is a difference is probably worth it, even if we agree that it doesn't really matter in these trivial cases.

Oh, and for a compiler I used to use it really did matter that you used "foreach" when you could, versus using "for ()", because it could dispatch things in parallel in the former case, and couldn't in the latter. So expressing the intent in the code itself and not just in the context really can matter.

The only nit I'll pick is re: the 2nd paragraph. I do agree that there is a difference in the expressions "isEven(n)" and "0==n%2" in isolation. But these expressions will always be surrounded by more code, and the degree of difference will entirely depend on that code and its structure. All of this can be very simply solved with a quick:

  function isEven(n) { return 0==n%2 } 

Admittedly, I had to be conscious of how I wrote that expression, but choosing meaningful variable names is also just part of writing code, and isEven() by itself likely doesn't provide enough context about why I'm checking for even-ness to begin with. These considerations all need to go into the design of the class/method, but at no point can the developer wash their hands of the need to provide context through standard practices, just because the standard library provided more descriptive methods.

And I'm not saying this is what you're saying, but the original comment seemed to believe that more expansive standard libraries are somehow inherently better. I'd argue they're just different, and more factors to consider when choosing a language. Sometimes they help. Sometimes they're not worth the price of admission.

I think the discussion could be generalized as: how far should standard libraries go? No matter how good that standard library is, at some point, I must apply the fundamental skill of adding context and structure to the code I write.