axios: Property 'Authorization' does not exists on type 'AxiosHeaders' after upgrade to 1.2.2

Here’s how I fixed it

config.headers = { ...config.headers } as AxiosHeaders;
config.headers.set('Authorization', token);

It is not intended and should be considered as a bug, but @jasonsaayman always needs a bit of time. I actually don’t get why he is the only one, who can create releases and how he can relax so long, when this library is so commonly used. Besides, it does not get less money through opencollective & co. No reaction after a week…

@tada5hi thanks for this let me address your concerns. I think saying I always need a bit of time is on the hot take side of things, I have been working on Axios for quite a while and before I started there were about 1k open issues, 200 open PRs and much fewer and less frequent releases. I am not “relaxing so long”, I have a real life too with commitments etc. To mention open collective and money is pretty tactless and in poor taste. I don’t personally gain anything from fundraising and don’t even use it to pay for axios-http.com domain or the hosting of that site which all come directly out of my own personal funds. We only collect money on open collective and GitHub so that we can apply it to things like issue hunt and if possible when funding looks good get someone onboard in a part-time position to help streamline the project.

I am currently the only person who can create a release, this is true, I am looking at making this more streamlined however that in itself is tricky as it can lead to poor-quality releases if not done correctly. Also as you said this is a very popular library and I don’t think handing out that ability to release to just anyone would be a good idea.

To address the SemVer issue, many times we release something and a side effect occurs that we don’t have enough tests to cover or check for this, in turn, causes that in the end our release was tagged with the incorrect version retrospectively. I know this is a problem and we are doing our best to make this happen less frequently. One of the ways we wanted to do this was pre-release’s however since so few people care to invest in the small amount of time it would take to install and test these pre-releases that route does not seem so viable so I am fully open to suggestions in this area and if anyone wants me to create a pre-release mailing list or some other way of notifying pre-release testers about these releases or implement something like a beta programme please let me know.

Lastly, this is a community-driven project, if you don’t like something reach out and we can work together to make it better and improve the project as a whole. Maybe add more tests or increase the effectiveness of the current suite to cover more impact areas. Help with pre-release testing, help with issues and aggregating and tagging them better, help with PR reviews or even suggestions on how to make releases better with fewer potential side effects and have a more solid pre-release testing programme etc. But don’t just leave a comment that shifts the blame solely onto me, that is not in the spirit of open source and that is not why I got involved in open source.

Try something like this if you are using Axios with TS -> (config.headers as AxiosHeaders).set('Authorization', token); it worked in my case.

Since this is a bug, rather than working around it with casting I chose to use @ts-expect-error so that typescript will complain when it is fixed.

Since the code still functionally worked even though the type didn’t say it would, I found this to be the least invasive change while still allowing the upgrade.

Wanted to share in case it helped anyone, thanks for all the time and effort the maintainers and contributors put into this library and its community. Have a great week all 🙂

V1.2.3 was released and fixed it.

I locked my version to 1.2.1 for now, until this is resolved

I was in 1.2.1 when it happened. Thought it was fixed in 1.2.2 so I upgraded. Still same issue.

just checked again, on 1.2.1 I don’t get this error. only on 1.2.2

Correct. The following can still be done in 1.2.1

config.headers = {
  ...config.headers,
  Authentication: token,
}
// Or
if (config.headers) {
  config.headers.Authorization = token
} else {
  config.headers = {
    Authorization: token,
  }
}

In production, there is always a rule - do not touch what works, unless you get a security vulnerability warning from npm. Therefore, new versions of packages should only be used in the development environment when you are trying out new features.

@DigitalBrainJS Here I would like to contradict you vehemently. This may be the case for end applications, but not for libraries that are built on top of them. A strategy like yours contributes to the fact that we live more and more in a dependency hell, where packages are based on different major, minor versions of the same package, which only increases the build size.

The only real solution here is to create prereleases for all versions, except for patches for broken versions (with hotfixes for the regression bug), which should be released ASAP. At the very least, this will increase the chance of finding a bug by the community, since despite many hundreds of automated tests, the coverage of the old code is not enough to have a good chance to find a regression bug before release. Another way to improve the user experience is to release only one feature/fix per version. But all of this requires automated releases to spend developers’ efforts on code, but not on chores.

I think we agree here that bug fixes should be fixed as soon as possible (ASAP). However, most libraries only maintain the current major version and bug fixes in an older major/minor version are not taken into account. This is another reason why you should not ( and most cases can not ) stay with old versions.

@tada5hi thanks for this let me address your concerns. I think saying I always need a bit of time is on the hot take side of things, I have been working on Axios for quite a while and before I started there were about 1k open issues, 200 open PRs and much fewer and less frequent releases. I am not “relaxing so long”, I have a real life too with commitments etc. To mention open collective and money is pretty tactless and in poor taste. I don’t personally gain anything from fundraising and don’t even use it to pay for axios-http.com domain or the hosting of that site which all come directly out of my own personal funds. We only collect money on open collective and GitHub so that we can apply it to things like issue hunt and if possible when funding looks good get someone onboard in a part-time position to help streamline the project.

First of all, I would like to apologize for the way I expressed my concerns and I greatly appreciate your work and that of the other contributors. I was just very frustrated that features that worked <v1.0 gradually stopped working during the v1+ releases and I would have been very happy about an earlier feedback from you no matter in which way in many of the problem cases. This started with issue #5089, where all at once the headers in the interceptor request were malformed, through content-encoding #5298 and the current one to name a few. Yes, that was not right of me to note open-collective and I am also quite aware that most of us do not get financial support for the work you do, I belong to a large extent to it. Most of us do it because we love programming and want to contribute and give back to others. I am very glad that there are such people and that contributes to my belief in humanity.

I am currently the only person who can create a release, this is true, I am looking at making this more streamlined however that in itself is tricky as it can lead to poor-quality releases if not done correctly. Also as you said this is a very popular library and I don’t think handing out that ability to release to just anyone would be a good idea.

I completely agree with you, and I fully understand when a new feature causes problems, but it shouldn’t circularly affect existing features. Besides, it is always good to test functions extensively before publishing them blindly on the left. This should also be the goal for all of us. I can highly recommend https://github.com/semantic-release/semantic-release to streamline release processes.

To address the SemVer issue, many times we release something and a side effect occurs that we don’t have enough tests to cover or check for this, in turn, causes that in the end our release was tagged with the incorrect version retrospectively. I know this is a problem and we are doing our best to make this happen less frequently. One of the ways we wanted to do this was pre-release’s however since so few people care to invest in the small amount of time it would take to install and test these pre-releases that route does not seem so viable so I am fully open to suggestions in this area and if anyone wants me to create a pre-release mailing list or some other way of notifying pre-release testers about these releases or implement something like a beta programme please let me know. Lastly, this is a community-driven project, if you don’t like something reach out and we can work together to make it better and improve the project as a whole. Maybe add more tests or increase the effectiveness of the current suite to cover more impact areas. Help with pre-release testing, help with issues and aggregating and tagging them better, help with PR reviews or even suggestions on how to make releases better with fewer potential side effects and have a more solid pre-release testing programme etc. But don’t just leave a comment that shifts the blame solely onto me, that is not in the spirit of open source and that is not why I got involved in open source.

As noted, I was just frustrated that certain features kept failing to work at one time or another and negatively impacted one or another production build. Among other things, the access token could not be updated in a microservice architecture because the interceptor header was corrupted #5089. Then a backend application of mine, with my part time work based on time sheduled task, failed to process an API request properly, which I only noticed when the task was triggered. Up to the api call which was done with axios, everything was tested #5298.

If you need support to review pull requests or structure the code, I’m very happy to help. I would also be happy to help you move the project to typescript, so you can also avoid some errors you might otherwise miss.

I would also like to apologize profusely at this point for the way and I completely agree with almost everything you said.

Many greetings Peter

Seems like another new release of 1.2.3 is happening here:

• https://github.com/axios/axios/pull/5448

It is not intended and should be considered as a bug, but @jasonsaayman always needs a bit of time. I actually don’t get why he is the only one, who can create releases and how he can relax so long, when this library is so commonly used. Besides, it does not get less money through opencollective & co. No reaction after a week…

I tried this and it works for me, you can also try it.

axiosInstance.interceptors.request.use( async (config) => { const token = await getItem(“jwtToken”); if (config.headers) (config.headers as AxiosHeaders).set(“Authorization”, Bearer ${token}); return config; }, (error) => Promise.reject(error), );

     if (typeof config.headers?.set === 'function') {
        config.headers.set('Authorization', `Bearer ${token}`);
      }

Wow, today I learned about @ts-expect-error. Cool!

Try something like this if you are using Axios with TS -> (config.headers as AxiosHeaders).set('Authorization', token); it worked in my case.

Thanks, this works for me

@DigitalBrainJS I guess this was introduced in the following line of PR #5375:

• https://github.com/axios/axios/pull/5375/files#diff-243f86a2e64131743ca04681df5d21438e79fcabe06f18029cb8dcef6a70121fR351

And seems like this issue is similar to what’s happening in this issue:

• #5415

hint for everyone: don’t use ^ and ~ in your package.json 😉

Have to agree with @tada5hi on upgrading packages in production apps. We run & maintain a large-scale application, and if we left package updates alone (except for vulnerabilities), we’d be amassing some serious technical debt (and time debt) as libraries we depend on continued to add non-breaking changes/features. Bottom line: avoid tech & time debt, review the changelogs in your dependencies and keep those packages up to date! Otherwise, it’s a much more daunting task down the road, and upgrading to a major version could be a lot more work.

I completely agree with you, and I fully understand when a new feature causes problems, but it shouldn’t circularly affect existing features.

@tada5hi Unfortunately, in the real world, this is practically unattainable. Regression bugs occur even in large commercial projects with huge QA departments. Users should not bump the package dependencies in production without QA testing before deploying, but judging by the issues, this happens. Usually, it doesn’t make sense for users to update the version of Axios if their code works. In production, there is always a rule - do not touch what works, unless you get a security vulnerability warning from npm. Therefore, new versions of packages should only be used in the development environment when you are trying out new features. The only real solution here is to create prereleases for all versions, except for patches for broken versions (with hotfixes for the regression bug), which should be released ASAP. At the very least, this will increase the chance of finding a bug by the community, since despite many hundreds of automated tests, the coverage of the old code is not enough to have a good chance to find a regression bug before release. Another way to improve the user experience is to release only one feature/fix per version. But all of this requires automated releases to spend developers’ efforts on code, but not on chores.

I locked my version to 1.2.1 for now, until this is resolved

I was in 1.2.1 when it happened. Thought it was fixed in 1.2.2 so I upgraded. Still same issue.

just checked again, on 1.2.1 I don’t get this error. only on 1.2.2