4 ms·

It's OK as long as you are in charge of when the updates happen. Your system is good in that it is a manually triggered process. It becomes a problem when a f

by snarfy 9y ago

It's OK as long as you are in charge of when the updates happen. Your system is good in that it is a manually triggered process. It becomes a problem when a full rebuild includes deleting external dependencies, downloading latest sources, and rebuilding everything. When that happens your build environment is a constant moving target. The problem grows exponentially with the number of dependencies you have. When you have a project with a 1000+ dependencies, all pulled latest, nothing will ever compile, let alone your own code.

stouset 9y ago
I semi-disagree. The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dependencies. If a specific issue is found with a newer version, then having the ability to explicitly pin to an old version is reasonable. > When you have a project with a 1000+ dependencies, all pulled latest, nothing will ever compile, let alone your own code. The problem is having a project with 1,000+ dependencies that are apparently such low quality that their authors issue build-breaking changes daily.
- snarfy 9y ago
  If you've ever done web development and peeked into your node_modules folder you'll understand this is a serious problem.
- KallDrexx 9y ago
  > The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dependencies. If a specific issue is found with a newer version, then having the ability to explicitly pin to an old version is reasonable. I'd argue dependencies should be manually updated constantly. While version pinning does allow you to accrue technical debt if your team has discipline it does allow you to manage the upgrade process and understand the impacts of a dependency upgrade. Even without obvious API changes it's possible that the implementation details of a library's method can cause your code to function differently, which can be caused by the introduction of a bug, the fixing of a bug your code didn't realize was a bug, or any minor quirks that may change between versions. When you manually upgrade you know exactly what to test and what to look for because (presumably) the person doing the dependency upgrade is someone who knows how the dependency is used. If you do not do manual upgrades but automatically update everything all the time bugs can sneak in and it won't always be easy to track down what caused it.
  - dionian 9y ago
    in my experience traceability of the versions of the dependencies used is as important as tracing that you use them... having that all in source control and being to replicate an immutable build from that tag at any time in the future is useful especially for large and complicated projects.
- zellyn 9y ago
  Well, if each of those 1,000 dependencies goes three years between accidental breaking changes, you still have a broken build every day on average…
- erik_seaberg 9y ago
  Perpetually-stale is just a pejorative way of saying known-good. You should update frequently, but only when you have time to test for problems and when it's not an especially bad day to cause an outage for your clients.
ssalazar 9y ago
> When you have a project with a 1000+ dependencies The Node concept of "package" management is really so different from traditional systems that they really shouldnt be discussed in the same context or as having the same concerns.

by snarfy 9y ago

stouset 9y ago

I semi-disagree. The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dependencies. If a specific issue is found with a newer version, then having the ability to explicitly pin to an old version is reasonable. > When you have a project with a 1000+ dependencies, all pulled latest, nothing will ever compile, let alone your own code. The problem is having a project with 1,000+ dependencies that are apparently such low quality that their authors issue build-breaking changes daily.

snarfy 9y ago
If you've ever done web development and peeked into your node_modules folder you'll understand this is a serious problem.
KallDrexx 9y ago
> The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dependencies. If a specific issue is found with a newer version, then having the ability to explicitly pin to an old version is reasonable. I'd argue dependencies should be manually updated constantly. While version pinning does allow you to accrue technical debt if your team has discipline it does allow you to manage the upgrade process and understand the impacts of a dependency upgrade. Even without obvious API changes it's possible that the implementation details of a library's method can cause your code to function differently, which can be caused by the introduction of a bug, the fixing of a bug your code didn't realize was a bug, or any minor quirks that may change between versions. When you manually upgrade you know exactly what to test and what to look for because (presumably) the person doing the dependency upgrade is someone who knows how the dependency is used. If you do not do manual upgrades but automatically update everything all the time bugs can sneak in and it won't always be easy to track down what caused it.
- dionian 9y ago
  in my experience traceability of the versions of the dependencies used is as important as tracing that you use them... having that all in source control and being to replicate an immutable build from that tag at any time in the future is useful especially for large and complicated projects.
zellyn 9y ago
Well, if each of those 1,000 dependencies goes three years between accidental breaking changes, you still have a broken build every day on average…
erik_seaberg 9y ago
Perpetually-stale is just a pejorative way of saying known-good. You should update frequently, but only when you have time to test for problems and when it's not an especially bad day to cause an outage for your clients.

ssalazar 9y ago

> When you have a project with a 1000+ dependencies The Node concept of "package" management is really so different from traditional systems that they really shouldnt be discussed in the same context or as having the same concerns.