Summary: the author updated a library without noticing and/or without knowing what version they were using before, because they aren't using lock files.
The library that broke was something using the AWS SDK. The library stopped working with an updated version of that AWS SDK.
They experimented with different package versions and combinations of service instances to fix the issue, because they didn't know what version of the package they were using in production before the package broke for them. They got an error message about a missing function in the updated library related to streams. That led to some false guesses about the source of the error.
The conclusion is that JS is not a serious programming language like Rust or C#.
Seems like they have complex CI/CD in place, but don't conclude that they should be pushing their package lock files.
And I don't understand at all how using another programming language would have prevented this issue.
Thanks for reading it! It's the first one to get comments on my blog lol.
Yes we did use lockfiles, all over the place. However each service had a different (and mandatory) security update that modified the libraries with a non-breaking change.
From now on I will try to establish a fixed policy although given the frequency of updates in the ecosystem it will become deprecated rather quickly
To me this sounds more like a "microservices nightmare"?
What do you mean by "the service had a mandatory security update" (paraphrased)?
I'm guessing you are talking about updating packages because of warnings from "npm audit"? Or do you mean an update of some top-level package? Container image??
Anyway, update is update.
And Software tied to cloud services can always be brittle. Why no complaint about Amazon breaking semver (if the mentioned missing function was part of the public API), or the package that was breaking (if it was not)?
As I already answered, if you are using packages that break sem-ver (it can happen very easily), or packages that depend ob unsprcified behavior of another package at a specifiv version, none of that is caused by the package manager or programming language.
I love me some JS hate from an informed IT expert, but sorry, as politely as I can put it, blaming common targets of unpopularity (JS) for your personal and/or organizational issues (not understanding dependency management) seems very unprofessional to me.
The word "mandatory" is a popular slippery slope, but from your description, I can at best guess what you meant and you haven't elaborated on it.
Dependencies are not magic, they are other peoples code. If you blindly update without understanding how anything works, you are in for pain.
Because your company doesn't do the same security update on testing server, thus creating difference between two services.
Npm is highly susceptible on this if you're using uncommon libraries, especially under 1 mil downloaded libraries. However the same can applies to any other toolings or languages that you use.
The library that broke was something using the AWS SDK. The library stopped working with an updated version of that AWS SDK.
They experimented with different package versions and combinations of service instances to fix the issue, because they didn't know what version of the package they were using in production before the package broke for them. They got an error message about a missing function in the updated library related to streams. That led to some false guesses about the source of the error.
The conclusion is that JS is not a serious programming language like Rust or C#.
Seems like they have complex CI/CD in place, but don't conclude that they should be pushing their package lock files.
And I don't understand at all how using another programming language would have prevented this issue.