Type mismatch between node headers and axios headers

[wrslatz]

Describe the bug

We have a common use-case of chaining certain request headers from inbound HTTP requests (in this case using express) along on outbound requests. Prior to axios v0.21.4 (specifically #3021), we didn't see type incompatibility pulling headers off of an express request and putting them directly into the outbound AxiosRequestConfig headers. With the new type, we now see

error TS2322: Type 'string | string[]' is not assignable to type 'string'

To Reproduce

import { AxiosRequestConfig } from 'axios';
import { Request } from 'express';

function addHeadersFromRequest(config: AxiosRequestConfig, request: Request): AxiosRequestConfig {
  config.headers['testheader'] = request.headers['testheader']; // error TS2322: Type 'string | string[]' is not assignable to type 'string'
}

Expected behavior

The types here used to work, though I am in favor of more strict types that actually represent what axios expects and supports. This doesn't seem like an uncommon use-case. I see two options here:

1. axios supports string[] header values, since these are a supported possibility in Node.js
2. axios does not support string[] header values, meaning library consumers need to adapt themselves
   • This would go against the recent change in Expand Headers types #4144

Environment

• Axios Version: "0.24.0"
• Adapter: HTTP
• Browser: N/A
• Browser Version: N/A
• Node.js Version: 12.20.1
• OS: MacOS 11.6.1
• Additional Library Versions

  "@types/node": "12.20.37",
  "@types/express": "4.17.13",
  "express": "4.17.1",
  

Additional context/Screenshots

The error here is because the express headers type comes from @types/node IncomingMessage, which has headers: IncomingHttpHeaders. For any headers not explicitly defined in IncomingHttpHeaders, the type is [header: string]: string | string[] | undefined;. This now mismatches with axios string value expectation.

Somewhat related to #4193 (type change causing issues) and #4141. It would be great if axios types better aligned with the raw node types, as this would provide a more consistent experience across the ecosystem, but I understand the desire not to make breaking changes (maybe part of v1 as others have suggested?).

[bfaulk96]

To build on this, as mentioned for the other types in #4144, I don't think it would hurt to add string[] to the allowed types anyway, since string[] can automatically be concatenated to a string type as well. That would also help deal with the issue mentioned in #4136

[estarossa0]

@bfaulk96 any pr regarding this or should I open one 😄?