4 ms·

Whether the package managers are poorly designed is completely ancillary. It really is primarily about developer laziness, incompetence, easiness. Proof: htt

Whether the package managers are poorly designed is completely ancillary. It really is primarily about developer laziness, incompetence, easiness. Proof: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ Sudden unplanned loss of availability is a catastrophic security problem, the A in the security CIA[1]. Worse is that the dependency that caused that problem was something that should never have been a dependency in the first place. Proper dependency management requires a degree of trust and integrity validation which are completely counter to automation. Most developers are eager to accept any resulting consequences because they don't own the consequences and because they are fearful of writing original code. [1] https://en.wikipedia.org/wiki/Information_security#Key_concepts https://en.wikipedia.org/wiki/Information_security#Key_conce...

ritchiea 6y ago
You can call it laziness but lots of developers correctly assume they'd be out of their jobs or at best out of favor at their company if they raised a fuss about dependency management rather than use (flawed) industry standard tools and get to work on features. No one gets fired for using npm, you might get fired for insisting you build your own dependency management system because npm is insecure rather than working on your team's domain problem.
- austincheney 6y ago
  > No one gets fired for using npm Most developers are eager to accept any resulting consequences because they don't own the consequences and because they are fearful of writing original code.
  - ritchiea 6y ago
    Some developers are fearful of writing original code. Others realize it's not going to be appreciated by their colleagues to write their own package manager to solve a problem most of the industry disregards. Imagine arguing for getting the "write our own package manager to replace npm/yarn/pip" ticket into a sprint.
    - austincheney 6y ago
      It isn't about writing your own package manager. At least start with not using every package offered by NPM or dependencies that do. If you cannot attest to every package in your dependency tree you have failed dependency management.
      - ritchiea 6y ago
        Ok so you're going to argue to an engineering manager or product manager that you need a day or days to do a full code audit of each external package you use? Or write your own library instead? That's, if anything, more unrealistic than just writing your own package manager. Do you actually get to do this wherever you work? Honestly it would be great to have the luxury of that kind of patience and time to invest in my work. But it's universally unrealistic in my experience. This is not at all a question of "what would be the ideal or perfect scenario." This is a question of what's pragmatic and politically accomplishable in most work environments.
        throwaheyy 6y ago
        Who said anything about requiring a full code audit? Parent post is suggesting being selective about which packages you consume and which third-party developers you trust, including transitive dependencies pulled in by any package you consume.
        HereBeBeasties 6y ago
        I just don't think that's realistic for the JavaScript ecosystem, for the majority of projects. E.g. The weight of something "standard" like create-react-app.
    - GrinningFool 6y ago
      Currently, managing dependencies correctly by vetting them with each and every version bump is huge amount of overhead and it grows with each dependency pulled in. The way we as an industry have been handling it has largely been to keep going like we don't need to. It's going to keep getting worse until a) developers and project managers realize doing inherently unsafe things is bad and b) they have the resources to give the additional ongoing levels of scrutiny. I'm not hopeful that this will happen at large in the industry, though I know it _is_ happening within individual companies and projects. I'm sure we'll mitigate the damage to some extent by making package managers smarter and implementing finer-grained permissions. That will improve the situation over time, but it also takes us in the wrong direction by allowing us to forget that when we're shipping dependencies, we ultimately own their behavior.
  - majormajor 6y ago
    Most devs would, however, end up owning the consequences of fully vetting their dependency tree when their manager gives them a terrible performance review for taking 20 times longer to do everything else than their peers. This can't change bottom up. Even if you went the professional licensing route you'd need top-down regulation to force companies to only higher vetted and licensed professionals, and to actually do verification of projects to make sure all your best practices were being followed and following up on penalizing developers who weren't.
Diggsey 6y ago
How is that proof? You're again pointing to a design flaw in NPM: that authors can easily delete packages without warning. If you yank a package with cargo, it doesn't break people's builds who already depend on that package, it just makes it harder to add new dependencies on the package.
- austincheney 6y ago
  Blaming NPM for that problem is not a cure. Your users don’t care about the sad tired pleadings of a developer about some distant information system in the cloud. All the users care about is that your software was unavailable. That is a security failure. Again, developers don’t care because they don’t own the consequences of such monumental failures, which is why they will happily and frequently repeat this deliberate mistake until they are terminated.

ritchiea 6y ago

You can call it laziness but lots of developers correctly assume they'd be out of their jobs or at best out of favor at their company if they raised a fuss about dependency management rather than use (flawed) industry standard tools and get to work on features. No one gets fired for using npm, you might get fired for insisting you build your own dependency management system because npm is insecure rather than working on your team's domain problem.

austincheney 6y ago
> No one gets fired for using npm Most developers are eager to accept any resulting consequences because they don't own the consequences and because they are fearful of writing original code.
- ritchiea 6y ago
  Some developers are fearful of writing original code. Others realize it's not going to be appreciated by their colleagues to write their own package manager to solve a problem most of the industry disregards. Imagine arguing for getting the "write our own package manager to replace npm/yarn/pip" ticket into a sprint.
  - austincheney 6y ago
    It isn't about writing your own package manager. At least start with not using every package offered by NPM or dependencies that do. If you cannot attest to every package in your dependency tree you have failed dependency management.
    - ritchiea 6y ago
      Ok so you're going to argue to an engineering manager or product manager that you need a day or days to do a full code audit of each external package you use? Or write your own library instead? That's, if anything, more unrealistic than just writing your own package manager. Do you actually get to do this wherever you work? Honestly it would be great to have the luxury of that kind of patience and time to invest in my work. But it's universally unrealistic in my experience. This is not at all a question of "what would be the ideal or perfect scenario." This is a question of what's pragmatic and politically accomplishable in most work environments.
      - throwaheyy 6y ago
        Who said anything about requiring a full code audit? Parent post is suggesting being selective about which packages you consume and which third-party developers you trust, including transitive dependencies pulled in by any package you consume.
        HereBeBeasties 6y ago
        I just don't think that's realistic for the JavaScript ecosystem, for the majority of projects. E.g. The weight of something "standard" like create-react-app.
  - GrinningFool 6y ago
    Currently, managing dependencies correctly by vetting them with each and every version bump is huge amount of overhead and it grows with each dependency pulled in. The way we as an industry have been handling it has largely been to keep going like we don't need to. It's going to keep getting worse until a) developers and project managers realize doing inherently unsafe things is bad and b) they have the resources to give the additional ongoing levels of scrutiny. I'm not hopeful that this will happen at large in the industry, though I know it _is_ happening within individual companies and projects. I'm sure we'll mitigate the damage to some extent by making package managers smarter and implementing finer-grained permissions. That will improve the situation over time, but it also takes us in the wrong direction by allowing us to forget that when we're shipping dependencies, we ultimately own their behavior.
- majormajor 6y ago
  Most devs would, however, end up owning the consequences of fully vetting their dependency tree when their manager gives them a terrible performance review for taking 20 times longer to do everything else than their peers. This can't change bottom up. Even if you went the professional licensing route you'd need top-down regulation to force companies to only higher vetted and licensed professionals, and to actually do verification of projects to make sure all your best practices were being followed and following up on penalizing developers who weren't.

Diggsey 6y ago

How is that proof? You're again pointing to a design flaw in NPM: that authors can easily delete packages without warning. If you yank a package with cargo, it doesn't break people's builds who already depend on that package, it just makes it harder to add new dependencies on the package.

austincheney 6y ago
Blaming NPM for that problem is not a cure. Your users don’t care about the sad tired pleadings of a developer about some distant information system in the cloud. All the users care about is that your software was unavailable. That is a security failure. Again, developers don’t care because they don’t own the consequences of such monumental failures, which is why they will happily and frequently repeat this deliberate mistake until they are terminated.