3 ms·

One app with 1,000 package dependencies? Sounds like a nightmare to me when it comes time to update them and ensure they didn't break anything... especially in

One app with 1,000 package dependencies? Sounds like a nightmare to me when it comes time to update them and ensure they didn't break anything... especially in a language without a compiler to help.

muraiki 11y ago
This is why they rely on semantic versioning. http://semver.org/ http://semver.org/ Edit: I know this doesn't solve the problem completely, but comparing, for instance, a typical CPAN module's versioning scheme with what you get in npm, I'm far more confident in a lack of breakage in the npm case. :) Edit2: For downvoters: I program in Perl and Javascript professionally. I'm speaking from experience (my boss just ran into this exact problem with a cpan module in production yesterday), not picking on Perl.
- BinaryIdiot 11y ago
  When you're looking at modules individually yeah semver is useful. When you're looking at modules that include other modules that include other modules? When one person makes the decision to upgrade then everyone either has to upgrade or not upgrade and I rarely see even big projects start a LTS version where they keep updating it; no most of them move on the second the next big version is released. This can be painful when you're dealing with a really big project and someone provides a security update but it's only for the newer version that has lots of breaking changes.
  - deleted 11y ago
    [deleted]
  - muraiki 11y ago
    Yes, I agree that this is a problem. You might be using foo in your project which gets a security update, and two things that depend on foo, where one of those things is using the still-vulnerable-foo. So you now have two versions of foo, including one that is vulnerable. I'm curious to know how other dynamic languages handle this. In Perl I think you generally can't safely load >1 version of the same module, so while you could end up with breakage on an update, you can't end up with the above security problem.

One app with 1,000 package dependencies? Sounds like a nightmare to me when it comes time to update them and ensure they didn't break anything... especially in a language without a compiler to help.

muraiki 11y ago

This is why they rely on semantic versioning. http://semver.org/ http://semver.org/ Edit: I know this doesn't solve the problem completely, but comparing, for instance, a typical CPAN module's versioning scheme with what you get in npm, I'm far more confident in a lack of breakage in the npm case. :) Edit2: For downvoters: I program in Perl and Javascript professionally. I'm speaking from experience (my boss just ran into this exact problem with a cpan module in production yesterday), not picking on Perl.

BinaryIdiot 11y ago
When you're looking at modules individually yeah semver is useful. When you're looking at modules that include other modules that include other modules? When one person makes the decision to upgrade then everyone either has to upgrade or not upgrade and I rarely see even big projects start a LTS version where they keep updating it; no most of them move on the second the next big version is released. This can be painful when you're dealing with a really big project and someone provides a security update but it's only for the newer version that has lots of breaking changes.
- deleted 11y ago
  [deleted]
- muraiki 11y ago
  Yes, I agree that this is a problem. You might be using foo in your project which gets a security update, and two things that depend on foo, where one of those things is using the still-vulnerable-foo. So you now have two versions of foo, including one that is vulnerable. I'm curious to know how other dynamic languages handle this. In Perl I think you generally can't safely load >1 version of the same module, so while you could end up with breakage on an update, you can't end up with the above security problem.