6 ms·

> How stupid of people to reuse small often used functions that only do one thing well. This is a straw man argument. The reason so many people are criticizing

by pdkl95 11y ago

> How stupid of people to reuse small often used functions that only do one thing well. This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. > trust their package manager That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen. The "stupid" part is pretending these have zero risk, and the part that makes some people angry is when they also have to depend on this zero-risk assumption transitively through another library. > It's not javascript devs fault that the standard library is so piss poor Nobody is claiming it was. However, Javascript devs are responsible when they add critical dependencies on external components. They are also responsible when they publish libraries that extend those critical dependencies to the people that use their library without a very good reason.

naasking 11y ago
> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.
- ksml 11y ago
  > The cost of a dependency for a good package manager is zero I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell
  - naasking 11y ago
    That's a good point that's not often considered. That sounds like it should be part of a package manager too, because all you need is a license compatibility matrix.
- apalmer 11y ago
  no this is the fundamental engineering issue... there is no magically mythical perfect package manager, and even if one exists there is a real intrinsic cost to adding a dependency. It is not a huge cost... it is minor... but the benefit of using a one line package is also minor... so when you are making a minor trade off over and over again as with npm where its not unsually to end up depending on 1000s of packages... then this is not a trade off that should be made without thinking... just saying be an engineer. weigh the costs
  - naasking 11y ago
    I never said perfect, I said good. Some basic properties are that upstream changes don't break downstream dependents if you've protected against automatic version updates.
    - marssaxman 11y ago
      And yet, automatic version updates seem to be the first thing people bring up in defense of package managers when I mention that I generally think they're a poor strategy. It's a lot like DLLs/shared libraries, actually: people marshal the same old arguments every time explaining why they are a great idea in theory, but in practice, there seems to be a whole hell of a lot of work being done to make up for the fragility you bring on board with a system like that, and I'd rather just embed the source or link it statically (depending on which context we're talking about here) so that I don't have to waste any time thinking about it.
- Manishearth 11y ago
  > The cost of a dependency for a good package manager is zero The recent left_pad fracas has proved that that is not the case. Snapshot dependencies in-tree? Sure. But a package manager based dependency will be predicated on trusting a lot of things.
  - naasking 11y ago
    I said a good package manager. The fact that the npm package database is fully mutable is a huge problem.
    - Manishearth 11y ago
      That still isn't enough to refute "The reason so many people are criticizing left-pad et al is about the cost of adding a dependency.". Sure, npm may be a bad package manager. If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was. Most other ecosystems, with good or bad package managers, do not have tiny one-function packages -- it's possible to have an ecosystem not depending on it. If npm isn't good enough to have zero-cost dependencies, then your ecosystem should definitely not depend on tiny packages. This may be NPM's fault, but it's the fault of the ecosystem too. For the record, I believe that npm is a pretty good package manager. And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken. Removing the "unpublish" feature (and using something like Cargo's yank) makes it harder for left_pad like incidences to happen, but you still have issues with broken package updates, etc. You can further solve this with global version pinning, but not everyone will do this so you're still stuck.
      - naasking 11y ago
        > If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was. That's great, and my point was that with a good package manager, that cost is effectively zero. > And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken. Automatic updates are a terrible idea, even if the developer purports to use "semantic versioning" and the update is supposed to be backwards compatible. Specifying a version should be mandatory. Your package manager could easily notify you that updates are available, but it should never update for you. That's as "easy" as updates should get, because anything else inevitably introduces silent breaking changes.
- deong 11y ago
  "Zero" isn't a cost of anything -- there's no free lunch. NPM, like any package manager, pretty much blindly accepts user input. I, as a module maintainer, could happily change every single function in my modules to function whatever() { return "WHHEEEEEEE!!!"; } and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's responsibility to vet changes. Obviously curated package managers like those used by most Linux distributions do carry some responsibility, but even then, there's not ZERO risk.
  - naasking 11y ago
    Except a good package manager will let you specify exactly which version you wish to depend upon, so any changes you make upstream will have no effect on people who protect themselves against automatic version updates. Seriously, the properties of good package management should be obvious by now. Any design that can break dependents and there's nothing they can do to protect themselves is broken.
    - efaref 11y ago
      That's just a no-true-scotsman fallacy. And pinning versions just means you lose automatic updates, which is surely the point of using a package manager in the first place. Otherwise you might as well just download the package and include it verbatim.
      - icebraining 11y ago
        No, it's not an NTS fallacy. And the package manager is mostly useful for tracking updates and simplify the process; having it automatically update is completely optional, and personally, I never do.
        naasking 11y ago
        Exactly. A notification that new updates are available would be nice, but I don't think automatic updates should be the default, even if "semantic versioning" says the update should be backwards compatible.
- coldtea 11y ago
  >The cost of a dependency for a good package manager is zero Only if one doesn't understand the notions of opportunity cost, code debt, and several other things besides...
xlm1717 11y ago
>The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen. Exactly. I'd like to know if andy_ppp reviews every update to packages that andy_ppp wants to include too.
- andy_ppp 11y ago
  Yes, I agree with you - there will always be some level of trust involved in your package manager. I think having a better standard library is probably the first desired solution, followed by npm keeping all old versions of a module around even after unpublishing and also some kind of review process build management system magic as part of your code review process. It's all very easy to say of course and loads of people having been saying including small piece of code from your package manager is wrong. I'm saying it's not and giving reasons why. Trust your package manager or help make it trust worthy I guess.
Alupis 11y ago
Not to mention, their package manager is governed by a single for-profit company, that could disappear at any time, taking the entire infrastructure with it (breaking everything...) There's a lot of talk of decentralizing npm - but come on folks, what motivation would npm the company have to do that? It's the same issue as with GitHub (only that, with GitHub at least, if you're using git properly, GitHub disappearing tomorrow should have little impact).
- Cthulhu_ 11y ago
  What motivation does Sonatype have for sponsoring Maven? What motivation do dozens of web hosters have with providing a free mirror for Debian or Ubuntu packages? As far as I know, NPM is not a profitable endeavour, so making it distributed would decrease costs, and the company behind it can focus on consultancy or whatever it is they do.
TimJRobinson 11y ago
Sounds like there's a market opportunity here for a company that does dependency verification. Send them a copy of your npm-shrinkwrap.json file and they ensure every dependency + sub dependency change is legitimate and has no obvious security holes. There are probably enterprises that would pay good money for this, especially 5+ years from now when these apps are much larger and harder to maintain.

by pdkl95 11y ago

naasking 11y ago

> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.

ksml 11y ago
> The cost of a dependency for a good package manager is zero I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell
- naasking 11y ago
  That's a good point that's not often considered. That sounds like it should be part of a package manager too, because all you need is a license compatibility matrix.
apalmer 11y ago
no this is the fundamental engineering issue... there is no magically mythical perfect package manager, and even if one exists there is a real intrinsic cost to adding a dependency. It is not a huge cost... it is minor... but the benefit of using a one line package is also minor... so when you are making a minor trade off over and over again as with npm where its not unsually to end up depending on 1000s of packages... then this is not a trade off that should be made without thinking... just saying be an engineer. weigh the costs
- naasking 11y ago
  I never said perfect, I said good. Some basic properties are that upstream changes don't break downstream dependents if you've protected against automatic version updates.
  - marssaxman 11y ago
    And yet, automatic version updates seem to be the first thing people bring up in defense of package managers when I mention that I generally think they're a poor strategy. It's a lot like DLLs/shared libraries, actually: people marshal the same old arguments every time explaining why they are a great idea in theory, but in practice, there seems to be a whole hell of a lot of work being done to make up for the fragility you bring on board with a system like that, and I'd rather just embed the source or link it statically (depending on which context we're talking about here) so that I don't have to waste any time thinking about it.
Manishearth 11y ago
> The cost of a dependency for a good package manager is zero The recent left_pad fracas has proved that that is not the case. Snapshot dependencies in-tree? Sure. But a package manager based dependency will be predicated on trusting a lot of things.
- naasking 11y ago
  I said a good package manager. The fact that the npm package database is fully mutable is a huge problem.
  - Manishearth 11y ago
    That still isn't enough to refute "The reason so many people are criticizing left-pad et al is about the cost of adding a dependency.". Sure, npm may be a bad package manager. If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was. Most other ecosystems, with good or bad package managers, do not have tiny one-function packages -- it's possible to have an ecosystem not depending on it. If npm isn't good enough to have zero-cost dependencies, then your ecosystem should definitely not depend on tiny packages. This may be NPM's fault, but it's the fault of the ecosystem too. For the record, I believe that npm is a pretty good package manager. And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken. Removing the "unpublish" feature (and using something like Cargo's yank) makes it harder for left_pad like incidences to happen, but you still have issues with broken package updates, etc. You can further solve this with global version pinning, but not everyone will do this so you're still stuck.
    - naasking 11y ago
      > If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was. That's great, and my point was that with a good package manager, that cost is effectively zero. > And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken. Automatic updates are a terrible idea, even if the developer purports to use "semantic versioning" and the update is supposed to be backwards compatible. Specifying a version should be mandatory. Your package manager could easily notify you that updates are available, but it should never update for you. That's as "easy" as updates should get, because anything else inevitably introduces silent breaking changes.
deong 11y ago
"Zero" isn't a cost of anything -- there's no free lunch. NPM, like any package manager, pretty much blindly accepts user input. I, as a module maintainer, could happily change every single function in my modules to function whatever() { return "WHHEEEEEEE!!!"; } and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's responsibility to vet changes. Obviously curated package managers like those used by most Linux distributions do carry some responsibility, but even then, there's not ZERO risk.
- naasking 11y ago
  Except a good package manager will let you specify exactly which version you wish to depend upon, so any changes you make upstream will have no effect on people who protect themselves against automatic version updates. Seriously, the properties of good package management should be obvious by now. Any design that can break dependents and there's nothing they can do to protect themselves is broken.
  - efaref 11y ago
    That's just a no-true-scotsman fallacy. And pinning versions just means you lose automatic updates, which is surely the point of using a package manager in the first place. Otherwise you might as well just download the package and include it verbatim.
    - icebraining 11y ago
      No, it's not an NTS fallacy. And the package manager is mostly useful for tracking updates and simplify the process; having it automatically update is completely optional, and personally, I never do.
      - naasking 11y ago
        Exactly. A notification that new updates are available would be nice, but I don't think automatic updates should be the default, even if "semantic versioning" says the update should be backwards compatible.
coldtea 11y ago
>The cost of a dependency for a good package manager is zero Only if one doesn't understand the notions of opportunity cost, code debt, and several other things besides...

xlm1717 11y ago

>The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen. Exactly. I'd like to know if andy_ppp reviews every update to packages that andy_ppp wants to include too.

andy_ppp 11y ago
Yes, I agree with you - there will always be some level of trust involved in your package manager. I think having a better standard library is probably the first desired solution, followed by npm keeping all old versions of a module around even after unpublishing and also some kind of review process build management system magic as part of your code review process. It's all very easy to say of course and loads of people having been saying including small piece of code from your package manager is wrong. I'm saying it's not and giving reasons why. Trust your package manager or help make it trust worthy I guess.

Alupis 11y ago

Not to mention, their package manager is governed by a single for-profit company, that could disappear at any time, taking the entire infrastructure with it (breaking everything...) There's a lot of talk of decentralizing npm - but come on folks, what motivation would npm the company have to do that? It's the same issue as with GitHub (only that, with GitHub at least, if you're using git properly, GitHub disappearing tomorrow should have little impact).

Cthulhu_ 11y ago
What motivation does Sonatype have for sponsoring Maven? What motivation do dozens of web hosters have with providing a free mirror for Debian or Ubuntu packages? As far as I know, NPM is not a profitable endeavour, so making it distributed would decrease costs, and the company behind it can focus on consultancy or whatever it is they do.

TimJRobinson 11y ago

Sounds like there's a market opportunity here for a company that does dependency verification. Send them a copy of your npm-shrinkwrap.json file and they ensure every dependency + sub dependency change is legitimate and has no obvious security holes. There are probably enterprises that would pay good money for this, especially 5+ years from now when these apps are much larger and harder to maintain.