81–90 of 238 posts
Earlier quoted context omitted.
But as Go puts it: “A little copying is better than a little dependency.” https://go-proverbs.github.io/
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
Earlier quoted context omitted.
Part of the benefit over a dependency is that the code added will (hopefully) be narrowly tailored to your specific need, rather than the generic implementation from a library that likely has support for unused features. Not including the unused features both makes the code you are adding easier to read and understand, but it also may be more efficient for your specific use case, since you don't have to take into acc…
But in a lot of cases you can't know all the dependencies, so you lean on the community trusting that a package solves the problem well enough that you can abstract it. You can pin the dependency and review the changes for security reasons, but fully grasping the logic is non-trivial. Smaller dependencies are fine to copy at first, but at some point the codebase becomes too big, so you abstract it and at that point i…
I see this as an absolute win. The state of micro dependencies of js was a nightmare that only happened because a lot of undereducated developers flooded the market to get that sweet faang money. Now that both have dried up I hope we can close the vault door on js and have people learn how to code again.
I see this as an absolute win. The state of micro dependencies of js was a nightmare that only happened because a lot of undereducated developers flooded the market to get that sweet faang money. Now that both have dried up I hope we can close the vault door on js and have people learn how to code again.
I don't see how the conclusion follows from this.
There will be many LLM-generated functions purporting to do the same thing, and a bug in one of them that gets fixed means only one project gets fixed instead of every project using an NPM package as a dependency.
> Sure, you could use blob-util, but then you’d be taking on an extra dependency, with unknown performance, maintenance, and supply-chain risks. Use of an AI to write your code is also a form of dependency. When the LLM spits out code and you just dump it in your project with limited vetting, that's not really that different from vendoring a dependency. It has a different set of risks, but it still has risks.
Right, but you do avoid worries like "will I have to update this dependency every week and deal with breaking changes?" or "will the author be compromised in a supply-chain attack, or do a deliberate protestware attack?" etc. As for performance, a lot of npm packages don't have proper tree-shaking, so you might be taking on extra bloat (or installation cost). Your point is well-taken, though.
This is not a worry with NPM. You can just specify a specific version of a dependency in your package.json, and it'll never be updated ever.
I have noticed for years that the JS community is obsessed with updating every package to the latest version no matter what. It's maddening. If it's not broke, don't fix it!
Earlier quoted context omitted.
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
Most of these util libraries require basically no changes ever. The problem is the package maintainers getting hacked and malicious versions getting pushed out.
So why not do the same thing with a dependency? Install it once and never update it (and therefore hacked and malicious versions can never arrive in your dependency tree).
You're a JS developer, right? That's the group who thinks a programmer's job includes constantly updating dependencies to the latest version constantly.
Earlier quoted context omitted.
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
> you just have to do maintenance through manual find-and-replace now Do you? It doesn't seem even remotely like an apples-to-apples comparison to me. If you're the author of a library, you have to cover every possible way in which your code might be used. Most of the "maintenance" ends up being due to some bug report coming from a user who is not doing things in the way you anticipated, and you have to adjust your l…
You don't actually. You write the library for how you use it, and you accept pull requests that extend it if you feel it has merit.
If you don't, people are free to fork it and pull in your improvements periodically. Or their fork gets more popular, and you get to swap in a library that is now better-maintained by the community.
As long as you pin your package, you're better off. Replicating code pretty quickly stops making sense.
Earlier quoted context omitted.
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
Copied text does not inject bitcoin mining malware three months after I paste it.
Earlier quoted context omitted.
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
Usually these types if things never change. I understand that all code is a liability, but npm takes this way too far. Many utility functions can be left untouched for many years if not forever.
Meanwhile Java goes the other way: twenty-year old packages that are serious blockers to improved readability. Running Java that doesn't even support Option (or Maybe or whatever it's called in Java).