[bluetech]

A dependency for uuid4 is hardly needed:

  crypto = require('crypto');

  function uuid4() {
      const bytes = crypto.randomBytes(16);
      bytes[6] = (bytes[6] & 0x0f) | 0x40;
      bytes[8] = (bytes[8] & 0x3f) | 0x80;
      return bytes.toString('hex').match(/(.{8})(.{4})(.{4})(.{4})(.{12})/).slice(1).join('-');
  }

[roblabla]

I mean sure. But I also need to parse UUID. And do other things with it. Even if I didn't need to, I'd still likely use the uuid-1345 crate for it.

Here's the thing: If I import this code in my codebase directly instead of using a library, it suddenly becomes my "responsibility" if it breaks. And when we're talking about a FOSS side-project, I don't have that kind of time. Third-party libraries means I get any improvements and bug-fixes for free. And if it breaks, I get to talk with the original maintainer to figure it out, and we're suddenly two people, with one hopefully knowledgable enough on the topic, working on the problem.

Importing this kind of thing in make codebase makes it an ugly unwieldy mess that will inevitably break, and I suddenly will be alone trying to figure out what I did wrong. This is what's good about npm and libraries: the community that's built around it.

[bluetech]

Well, surely you put the line somewhere? Would you depend on `leftpad`? How about `is-odd`?

Your view of dependencies is very idealistic. And if I'd venture to guess - apologies if I'm wrong - young, at least to programming. I'm saying this because you don't tend to hear such phrases once reality hits.

Everything you said can be flipped:

> If I import this code in my codebase directly instead of using a library, it suddenly becomes my "responsibility" if it breaks.

I have full control & understanding of the code; I can adjust & trim so it fits as much as possible. If it breaks, I can fix it directly.

> And when we're talking about a FOSS side-project, I don't have that kind of time.

Copying/hand rolling some trivial code is often faster than deciding among a dozen libraries which do the same thing, reading their docs, their issue pages and open PRs, adding and integrating to my project.

> Third-party libraries means I get any improvements and bug-fixes for free.

I must keep the dependencies updated. I must read changelogs and hope nothing breaks.

> And if it breaks, I get to talk with the original maintainer to figure it out

I must use inefficient communication with a more-often-than-not absent maintainer in order to resolve my problem instead of fixing it directly.

> I suddenly will be alone trying to figure out what I did wrong

I am able to be self-reliant in fixing the problem, because I wrote the code and I understand it.

I do not have to trust the maintainer of the package or the maintainers of any of its transitive dependencies to be competent or non-evil.

---

For some things this is worth it. IMO for generating 16 random bytes it is not worth it.

[roblabla]

Well, everything I've said here are grounded in personal experience working on FOSS projects. They're also grounded in trust of the maintainers. In 5 years of full-time programming as a job and a hobby, I have found that to work to my advantage. I can understand that this might not be everyone's experience. I also understand that different projects have different needs - some might simply be too sensitive to depend on external code if they can help it.

To answer your rhetorical questions: I would certainly depend on leftpad, as it allows me to free my mind to something more useful. I probably wouldn't depend about is-odd because I intuitively know how to make it work. That's pretty personal. The line is basically drawn at "do I need to think to figure this out." Yes, leftpad is trivial. But this is death by the thousand papercuts: When I program something, I'm solving a problem. Having to solve a million other problems at the same time - no matter how trivial - is going to take me away from what I'm supposed to actually doing. It breaks my flow. I don't like that.

> Copying/hand rolling some trivial code is often faster than deciding among a dozen libraries which do the same thing, reading their docs, their issue pages and open PRs, adding and integrating to my project.

I have found this to not be the case. In the JS land, depending on a library is beyond trivial. Especially for those "simple" libraries that simply export a function. Yes, I do need to read the docs, but there isn't a million ways to do leftpadding, nor is there a million ways to do UUID generation. Copy pasting code might require playing with requires, figuring out transitive dependencies, and just some manual work that take time away from actually thinking about the code I'm working on - again, breaking my flow, forcing me to context switch.

> I must keep the dependencies updated. I must read changelogs and hope nothing breaks.

Semver takes care of that for you. And yes, I trust maintainers to follow semver. Again, that generally works. I only had a single case of semver-breaking release in my life, and that was in the Rust land - docopt.rs 0.8.2. https://github.com/docopt/docopt.rs/issues/235. Debugging the issue took me at most an hour, reporting it to upstream took seconds, and the fixed version was released literally 10 minutes later. In the meantime, my install still worked due to the lockfile pinning the previous docopt version. I could easily continue working normally.

Breakage happen. I've found that breakage also happen internally. Sometimes I change my code and break my own invariants. Refactor and forget to fix an instance, which breaks the code in subtle ways. Bugs happen. I accept that.

> I have full control & understanding of the code; I can adjust & trim so it fits as much as possible. If it breaks, I can fix it directly.

This is where I totally disagree. Depending on a third-party package does not deprive me of the ability to fix code when it breaks. And in fact: it empowers me. Again, the major advantage of dependencies, in my view, comes from the community. And if it needs adjustment that could be beneficial to others, I can PR it. I can fork, and npm has tools to make it easy to inject a fork into the dependency tree, replacing all instances with my own. This lets me experiment with potential fixes with ease, as if it was my own code.

Sure, sometimes, the library might not do exactly what I want it to, exactly how I want it to. Maybe what I want to do is incompatible with said libraries. In those cases, rolling my own might make sense.

In the end, it comes down to this: I trust the community, and believe in taking and giving back. If that's a young point of view, then so be it. Maybe I'll learn the hard way that reality is not so forgiving, that my trust was misplaced.

[_wmd]

v1 and v2 UUIDs are derived from a MAC address by specification, the uniqueness of the v1 scheme in particular depends on it. Whether that's a good idea or not is another topic entirely, but if you want to conform to spec, an implementation needs to be able to read MAC addresses

[bluetech]

Please see the comment I replied to.