Node.js HTTP client axios pushes broken update breaking production apps(github.com)
github.com
Node.js HTTP client axios pushes broken update breaking production apps
https://github.com/axios/axios/issues/5038
25 comments
This should affect people only if they're not using specific versions and not using package-lock.json. It's exactly what those features are meant to do, updating should be a deliberate action. It's really bad that it's affected production sites so the devs will hopefully make use of package lock.
The sad fact is that the number of users who have good testing of their HTTP client is smaller than the number of people who have automatic dependency updates or would merge without successfully testing this.
With unit testing it us generally considered bad practice to test your dependencies and many people don't have good integration tests.
With unit testing it us generally considered bad practice to test your dependencies and many people don't have good integration tests.
Either way people should not pull in new versions of dependencies and automatically deploy those to prod. One of the comments mentioned a app store review, which means that they pull in unpinned versions in a app that they cannot update by themselves. That is crazy.
To be fair, the Axios docs also suggest using the hosted package as well which I assume would also lead to the same situation.
https://github.com/axios/axios#installing
https://github.com/axios/axios#installing
All these comments on GitHub are amazing to me. How do you let a new build of your project with a new version of a such a fundamental dependency get deployed to _production_ without being tested first, manually or otherwise?
My guess is they didn't deploy a new version but rather they used a CDN... for a mobile app... I can't even.
Not pinning and not testing is egregious enough but to use a CDN for a web-based cross-platform app? Absurd.
Not pinning and not testing is egregious enough but to use a CDN for a web-based cross-platform app? Absurd.
More specifically: A public CDN whose content they don't own, and that can change at any point in time.
If it would be a private CDN which points only to the content they explicitly published as part of a build&release process they wouldn't have the problem.
If you rely on public artifacts that others published, all your availability and security guarantees are gone.
If it would be a private CDN which points only to the content they explicitly published as part of a build&release process they wouldn't have the problem.
If you rely on public artifacts that others published, all your availability and security guarantees are gone.
Yeah, you should definitely ask for a refund!
Here's the refund form: https://notepad-plus-plus.org/news/v843-unhappy-users-editio...
You misunderstand me. I'm not criticizing the axios developers, I'm criticizing downstream developers that blindly deploy new versions to production.
Many of these products are likely commercial based on their comments
Many of these products are likely commercial based on their comments
That comment section in github is just littered with stupid.
If you have a dependency like this that could be production breaking then lock it down. Do not upgrade it without someone looking at it. Or have a set of tests that do that for you.
Axios broke something but who cares. If your build broke or your application broke then you have something to fix not the axios devs.
It is too bad github does not have a "put on your bigboy pants" icon.
If you have a dependency like this that could be production breaking then lock it down. Do not upgrade it without someone looking at it. Or have a set of tests that do that for you.
Axios broke something but who cares. If your build broke or your application broke then you have something to fix not the axios devs.
It is too bad github does not have a "put on your bigboy pants" icon.
Anyone who allowed this to hit production should take a serious look at their testing process. This basically looks like axios's get method, which is probably a core use of the library, simply went missing. This should not have been a difficult issue for the most basic automated testing library or manual testing process to identify.
That being said, the ultimate culprit here is the nodeJS system. npm install will add the package with it being setup to upgrade to the latest minor version by default, instead of the obvious choice of fixing it to the specific version that was installed.
Further, the package-lock.json technology is neither well explained by NodeJS, nor well documented. The process one should use is not well explained either. And often fairly trivial changes will lead to significant changes in package-lock.json.
That being said, the ultimate culprit here is the nodeJS system. npm install will add the package with it being setup to upgrade to the latest minor version by default, instead of the obvious choice of fixing it to the specific version that was installed.
Further, the package-lock.json technology is neither well explained by NodeJS, nor well documented. The process one should use is not well explained either. And often fairly trivial changes will lead to significant changes in package-lock.json.
It looks like at least some of the individuals claiming production issues are pulling the latest version of Axios from a CDN. It doesn't seem like they actively pushed a release to production without adequate testing. Not that I disagree with your overall point, but it's at least a little bit less damning.
All those people saying that this is unacceptable negligence from the developers should request a refund. I'm sure they'll get all the money they paid for Axios back in no time.
I have seen this kind of thing(no lock files) in few of recent clients' work when trying to fix their issues that came "out of nowhere" after recent deployment, as they said.
Lockfiles in Node do not work well. Many projects outright disable them and instead pin dependencies. They were designed and implemented in a rush, and it shows.
Mostly a backend dev but worked on a few projects with NPM… so how does this even happen? Devs just updating axios without looking at it just because?
why do people still use axios?
what are good alternatives?
fetch?
Fetch is low level. Axios is battery-included
Low level? Really? Can you point something that is achieved on axios with few lines of code that fetch couldn't do it with few lines of code too? I can't considerate fecth.get().then(res => res.json().then(data => /.../)) A Low level thing.
I don't use axios often, but if I need to intercept requests, or set global headers I always need to wrap my fetch function and creating my own "axios". Axios can do these things without hassle.
Even if some difference actually matters (e.g. setting a timeout), it would be wise to wrap axios or fetch in a custom function, which obviates the need to use either for most developers using the codebase.