3 ms·

I guess my comment appears rude, which wasn't intended, I just find npm a troublesome piece of software that is passable as a package manager for the javascript

I guess my comment appears rude, which wasn't intended, I just find npm a troublesome piece of software that is passable as a package manager for the javascript ecosystem, but not a tool one solves problems with if there are viable alternatives.

murukesh_s 6y ago
why is it trouble? why can't they improve it even if its trouble?
deleted 6y ago
[deleted]
folkrav 6y ago
When you have one thing to nail and already own a hammer, why go and buy another one? Even if it's not a good one, it's gonna do the job, and be the least trouble.
- andreareina 6y ago
  The choice of package manage is much stickier than the choice of hammer. I can trivially change hammers between projects or even between nails. Changing package managers is a lot more involved, and gets more involved as it's used more---and they've just established a precedent for using npm to package go binaries.
  - detaro 6y ago
    They established the choice of npm when they choose to be a JS shop, that's exactly their argument.
    - andreareina 6y ago
      Sorry I wasn't clear, I'm not making an argument for or against npm, only responding to the analogy. But I wouldn't consider "we're already using X" to be sufficient reason to use X for something it wasn't designed around. Again, these choices are sticky and tend to be vulnerable to scope creep. I'd call it a textbook case of technical debt, and it's ok to point that out. They might have forestalled the criticism by acknowledging that, but they didn't.
  - folkrav 6y ago
    Meh, depends. For their case, for an internal CLI tool that will get used interactively on development environments, it's fine, the cost of switching is not very heavy. At worst they're postponing the work of deploying on other package managers, and devs will have to run 2-3 commands to remove the npm package, configure whatever next place it gets deployed to and install the new executable. Not a big deal at all.
    - andreareina 6y ago
      Sure, should have s/much stickier/sticker/. I'm not going to comment on whether the tradeoffs are worth it, I just thought the hammer analogy doesn't work due to material differences in how you switch between hammers vs package managers.
knuthsat 6y ago
I don't know why but I never encountered issues using npm.
- sli 6y ago
  I've had far more problems with yarn, which sometimes decides it and it alone not longer has internet access and none of the "fixes" published over the years have worked. Instead, you have to just set your timeout really, really high. That's been the only fix for a good while, and it frequently does not work. Older NPM could be a pain but modern NPM is pretty smooth and works just fine.

murukesh_s 6y ago

why is it trouble? why can't they improve it even if its trouble?

deleted 6y ago

[deleted]

folkrav 6y ago

When you have one thing to nail and already own a hammer, why go and buy another one? Even if it's not a good one, it's gonna do the job, and be the least trouble.

andreareina 6y ago
The choice of package manage is much stickier than the choice of hammer. I can trivially change hammers between projects or even between nails. Changing package managers is a lot more involved, and gets more involved as it's used more---and they've just established a precedent for using npm to package go binaries.
- detaro 6y ago
  They established the choice of npm when they choose to be a JS shop, that's exactly their argument.
  - andreareina 6y ago
    Sorry I wasn't clear, I'm not making an argument for or against npm, only responding to the analogy. But I wouldn't consider "we're already using X" to be sufficient reason to use X for something it wasn't designed around. Again, these choices are sticky and tend to be vulnerable to scope creep. I'd call it a textbook case of technical debt, and it's ok to point that out. They might have forestalled the criticism by acknowledging that, but they didn't.
- folkrav 6y ago
  Meh, depends. For their case, for an internal CLI tool that will get used interactively on development environments, it's fine, the cost of switching is not very heavy. At worst they're postponing the work of deploying on other package managers, and devs will have to run 2-3 commands to remove the npm package, configure whatever next place it gets deployed to and install the new executable. Not a big deal at all.
  - andreareina 6y ago
    Sure, should have s/much stickier/sticker/. I'm not going to comment on whether the tradeoffs are worth it, I just thought the hammer analogy doesn't work due to material differences in how you switch between hammers vs package managers.

knuthsat 6y ago

I don't know why but I never encountered issues using npm.

sli 6y ago
I've had far more problems with yarn, which sometimes decides it and it alone not longer has internet access and none of the "fixes" published over the years have worked. Instead, you have to just set your timeout really, really high. That's been the only fix for a good while, and it frequently does not work. Older NPM could be a pain but modern NPM is pretty smooth and works just fine.