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

[andreylh]

Summary

I'm getting the following error after upgrading axios to version 1.2.2:

TS2339: Property 'Authorization' does not exist on type 'AxiosHeaders | Partial<RawAxiosHeaders & MethodsHeaders & CommonHeaders>'.
Property 'Authorization' does not exist on type 'AxiosHeaders'

The same snippet of code is working on version 1.2.1:

import axios from 'axios';

axios.interceptors.request.use((request) => {
    request.headers
        ? (request.headers.Authorization = `Bearer ${token}`)
        : (request.headers = { Authorization: `Bearer ${token}` });
});

Environment

• Axios 1.2.2
• Node.js 18.12.1
• OS: Ubuntu 20.04.4 LTS (WSL2)

[karlhorky]

@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:

• Broken AxiosHeaders typings #5415

[karlhorky]

Oh, maybe it's already fixed in this PR:

• fix(types): fixed AxiosRequestConfig header interface by refactoring it to RawAxiosRequestConfig; #5420

[AmosSzust]

Having the same issue so following...

[kirill-linnik]

same here, rolling back version update so far

[tada5hi]

@jasonsaayman would be great if you could create a hot fix release ( semver patch ) with #5420.

[xgenem]

Here's how I fixed it

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

[cmario92]

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

[xgenem]

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.

[cmario92]

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

[xgenem]

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,
  }
}

[crypt096]

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

[ruiaraujo012]

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

[DercilioFontes]

I could solve it using the following:

const headers = { ...config.headers } as Partial<AxiosRequestHeaders>;
headers['appversion'] = `${environment.versionNumber}.${environment.buildNumber}`;
headers['timezone_name'] = dayjs.tz.guess();
headers['content-location'] = dayjs.tz.guess();
headers['Authorization'] = `Bearer ${token}`;
...

[sbahman]

I am also having this issue - could anyone clarify if this is an intended behaviour after 1.2.2 or is this a "bug" which will likely be fixed in a future release?

[tada5hi]

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....

[andreylh]

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....

This is a bug because according to Semantic Versioning, incrementing the patch number must be backward compatible. In this case, the pipeline of a system using version "~1.2.0" or "~1.2.1" will fail

[dteknolove]

Here's how I fixed it

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

thanks.. it work for me to

[jasonsaayman]

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.

[tada5hi]

@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

[jasonsaayman]

@tada5hi thanks for your reply. Can you reach out to me by email, then we can discuss some aspects further?

[tada5hi]

@jasonsaayman With pleasure, I would also like to thank you for your detailed and kind message.
I will be very happy to do so.

[kirill-linnik]

folks, all of us have bugs in our software and @jasonsaayman raised a good point: this package needs more tests. how can we help and who wants to jumb on board?

[xgenem]

It's really not a problem without a workaround so it should all be okay. We shouldn't be too hard on this. Keep up the good work @jasonsaayman !

[DigitalBrainJS]

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.

[tada5hi]

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.

[ffxsam]

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.

[DigitalBrainJS]

@tada5hi I am not saying that packages should not be updated at all, I am just saying that updating packages should be done consciously, tested in the development environment, and only then updated on the production server. Unless you have a practical reason to upgrade a package, it's best to refrain from upgrading just for the sake of upgrading.
There should not be a situation where a package update is an untested artifact, and even more so there should not be a situation where a package update happens directly in production via npm install without the CI option. The production server must strictly use the package-lock file.
If the Axios bug broke the entire production server, then this most likely indicates that the problem exists in the user CI / CD as well.

[tada5hi]

@tada5hi I am not saying that packages should not be updated at all, I am just saying that updating packages should be done consciously, tested in the development environment, and only then updated on the production server. Unless you have a practical reason to upgrade a package, it's best to refrain from upgrading just for the sake of upgrading. There should not be a situation where a package update is an untested artifact, and even more so there should not be a situation where a package update happens directly in production via npm install without the CI option. The production server must strictly use the package-lock file. If the Axios bug broke the entire production server, then this most likely indicates that the problem exists in the user CI / CD as well.

@DigitalBrainJS i never claimed that testing in the development environment was or should be skipped.
But in general, the content here is slowly going in the wrong direction, if I can note that. But I always like to exchange via discord, slack or email, if you want ✌️ 😊

[karlhorky]

Since #5420 was merged and released in axios@1.2.3, it seems like this issue is also fixed.

@andreylh can you confirm and close if so?

[kirill-linnik]

hint for everyone: don't use ^ and ~ in your package.json ;)

[ffxsam]

@kirill-linnik Nothing wrong with ^ which is pretty safe. The key thing is to always interactively upgrade your repos (e.g. pnpm up -i or pnpm up --latest -i) and review everything carefully. Doing a blind upgrade is reckless.

[SimonVillage]

on npm we still have 1.2.2

[karlhorky]

Oh, looks like the axios@1.2.3 release was deleted. @DigitalBrainJS @jasonsaayman any feedback here?

[karlhorky]

Seems like another new release of 1.2.3 is happening here:

• [Release] v1.2.3 #5448

[coo-kiee]

내가 고친 방법은 다음과 같습니다.

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

It's not help to me

I sovled it:

axiosInstance.interceptors.request.use(
    (config) => {
        const tempHeader= config.headers as any;
        tempHeader.Authorization = localStorage.getItem(TOKEN_KEY);
        config.headers = tempHeader;

        return config;
    },
);

[kkirsche]

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 🙂

[ffxsam]

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

[marsDes]

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

[AmosSzust]

Am I missing something or 1.2.3 was not released eventually?
Is there a problem with it?
Thanks

[xgenem]

I think it was reverted? Not sure. But for now this should help you

v1.2.2

api.interceptors.request.use((config) => {
    const token = '1231231'
    config.headers = { ...config.headers } as AxiosHeaders
    config.headers.set('Authorization', token) 
    return config;
});

[AmosSzust]

I saw the many fixes in this thread but I was wondering if there's another issue that prevents this fix from being formally released.

[CurpraCode]

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),
);

[DercilioFontes]

V1.2.3 was released and fixed it.

[karlhorky]

@andreylh can you confirm that axios@1.2.3 fixes the issue? And then close this if it's working now?

[tada5hi]

Dont't upgrade rash to v1.2.3, it might cause problems :/
#5476