Description
When using this library in a backend (e.g. for testing HTTP servers), it is reasonable to assume Node might be used (it works fine during runtime since Node supports the Fetch API). Currently, the generics used by this library rely on the HeadersInit type which is available in some TS environments but not others (the lib option in the TSConfig file seems to determine this; it looks like it is available if lib has 'DOM' in it). The @types/node package declares the Headers type, but not HeadersInit. The HeadersInit type seemingly becomes unresolved if @types/node is used but not the 'DOM' lib.
Proposal
I think this problem could be solved by removing the dependency of this package on the 'DOM' lib by altering the tsconfig file. The HeadersInit type could be defined as follows:
typeHeadersInit=NonNullable<ConstructorParameters<typeofHeaders>[0]>;
Then again, the Headers type and other fetch types do need to come from somewhere. I'm not sure what would be most appropriate; maybe they could be bundled with the declaration files somehow.
Checklist
Description
When using this library in a backend (e.g. for testing HTTP servers), it is reasonable to assume Node might be used (it works fine during runtime since Node supports the Fetch API). Currently, the generics used by this library rely on the
HeadersInittype which is available in some TS environments but not others (theliboption in the TSConfig file seems to determine this; it looks like it is available iflibhas'DOM'in it). The@types/nodepackage declares theHeaderstype, but notHeadersInit. TheHeadersInittype seemingly becomes unresolved if@types/nodeis used but not the'DOM'lib.Proposal
I think this problem could be solved by removing the dependency of this package on the
'DOM'lib by altering the tsconfig file. TheHeadersInittype could be defined as follows:Then again, the
Headerstype and other fetch types do need to come from somewhere. I'm not sure what would be most appropriate; maybe they could be bundled with the declaration files somehow.Checklist