9 ms·

I don’t get why anyone would introduce a dependency this small to their codebase. It’s a much better choice to just copy the source code and possibly license i

I don’t get why anyone would introduce a dependency this small to their codebase. 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.

bin_bash 4y ago
I think a lot of it is from a single engineer: sindresorhus 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-9238d977a92a https://blog.sindresorhus.com/small-focused-modules-9238d977... Most projects will include at least one package by him in the dependency tree.
- sanitycheck 4y ago
  Funnily enough, I was just digging through my current project's dependencies and he's slipped in via a Rollup plugin which uses his "globby" package, which in turn uses his "slash" package.. Slash is about 5 lines of code, which is roughly 4 more than most people need for what it does. 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.
- nobleach 4y ago
  For years, the bane of my existence was always lodash. Import one tiny utility and it brings along 15 of its closest friends. You can't get away from it. It was built so incredibly modularly, that it has to import a bunch of other things. Now most folks will quickly rush to its defense and tell you that Webpack should be able to tree-shake it well enough. My actual experience is that it was a tremendous waste of my customers' bandwidth. Seeing LoDash as a dependency of anything I use is an immediate NOPE for me. I've yet to see anything it provides that I couldn't just do myself. 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.
  - sanitycheck 4y ago
    I'm the opposite, I tend to be relieved when I see lodash as a dependency. In any normal sized project I'm probably already using it, or it's already a dependency of a dependency. I trust it a lot more than a hundred tiny libs by random authors, both in terms of sketchy behaviour and reliability/performance. If I need to target platforms which don't support modern JS I vastly prefer to stick to lodash than use a bunch of polyfills of unknown quality. 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.
thatwasunusual 4y ago
> I don’t get why anyone would introduce a dependency this small to their codebase. 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."
- xboxnolifes 4y ago
  I feel it's more likely related to how often "don't reinvent the wheel" and "NIH syndrome" is thrown around. It's no surprise to me that people will first check to see if a library already exists before going to write their own, probably lacking function.
- BigJono 4y ago
  Let's call a spade a spade. It's a bunch of noobs that have become the majority and created a culture of dependency-first development. 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.
  - ratww 4y ago
    If we're going to call a spade a spade, then let's go ahead and say that the majority of the packages that are always referenced in those discussions (is-even, is-odd, etc) is maintained and primarily used by a minority of developers that are very well known in the ecosystem. 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.
duxup 4y ago
I find that I do that more often now than ever. 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.
- megous 4y ago
  And you can easilly add the features you actually need. :)
Merad 4y ago
4-5 years ago (when the popularity of node was skyrocketing but es6 was still relatively new) I remember some people arguing passionately that it was good to maximize code reuse, i.e. better to pull in a package with one utility than to write 5 lines of code in your own application. I think it was mainly a symptom of the gaping holes in javascript's standard library... thankfully that attitude seems to have mostly died off.
chrisfosterelli 4y ago
At risk of criticism, I'll bite. I used to think this way and include a lot of small dependencies in most projects I worked on. 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.
- pilif 4y ago
  > Of course you could just copy the code, but then that increases LOC in my codebase that I'm responsible for. 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.
  - tylersmith 4y ago
remram 4y ago
> possibly license into your own code 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.

bin_bash 4y ago

I think a lot of it is from a single engineer: sindresorhus 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-9238d977a92a https://blog.sindresorhus.com/small-focused-modules-9238d977... Most projects will include at least one package by him in the dependency tree.

sanitycheck 4y ago
Funnily enough, I was just digging through my current project's dependencies and he's slipped in via a Rollup plugin which uses his "globby" package, which in turn uses his "slash" package.. Slash is about 5 lines of code, which is roughly 4 more than most people need for what it does. 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.
nobleach 4y ago
For years, the bane of my existence was always lodash. Import one tiny utility and it brings along 15 of its closest friends. You can't get away from it. It was built so incredibly modularly, that it has to import a bunch of other things. Now most folks will quickly rush to its defense and tell you that Webpack should be able to tree-shake it well enough. My actual experience is that it was a tremendous waste of my customers' bandwidth. Seeing LoDash as a dependency of anything I use is an immediate NOPE for me. I've yet to see anything it provides that I couldn't just do myself. 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.
- sanitycheck 4y ago
  I'm the opposite, I tend to be relieved when I see lodash as a dependency. In any normal sized project I'm probably already using it, or it's already a dependency of a dependency. I trust it a lot more than a hundred tiny libs by random authors, both in terms of sketchy behaviour and reliability/performance. If I need to target platforms which don't support modern JS I vastly prefer to stick to lodash than use a bunch of polyfills of unknown quality. 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.

thatwasunusual 4y ago

> I don’t get why anyone would introduce a dependency this small to their codebase. 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."

xboxnolifes 4y ago
I feel it's more likely related to how often "don't reinvent the wheel" and "NIH syndrome" is thrown around. It's no surprise to me that people will first check to see if a library already exists before going to write their own, probably lacking function.
BigJono 4y ago
Let's call a spade a spade. It's a bunch of noobs that have become the majority and created a culture of dependency-first development. 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.
- ratww 4y ago
  If we're going to call a spade a spade, then let's go ahead and say that the majority of the packages that are always referenced in those discussions (is-even, is-odd, etc) is maintained and primarily used by a minority of developers that are very well known in the ecosystem. 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.

duxup 4y ago

I find that I do that more often now than ever. 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.

megous 4y ago
And you can easilly add the features you actually need. :)

Merad 4y ago

4-5 years ago (when the popularity of node was skyrocketing but es6 was still relatively new) I remember some people arguing passionately that it was good to maximize code reuse, i.e. better to pull in a package with one utility than to write 5 lines of code in your own application. I think it was mainly a symptom of the gaping holes in javascript's standard library... thankfully that attitude seems to have mostly died off.

chrisfosterelli 4y ago

At risk of criticism, I'll bite. I used to think this way and include a lot of small dependencies in most projects I worked on. 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.

pilif 4y ago
> Of course you could just copy the code, but then that increases LOC in my codebase that I'm responsible for. 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.
- tylersmith 4y ago

remram 4y ago

> possibly license into your own code 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.