New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Types of property 'headers' are incompatible (with new 3.1.0) #95
Comments
The problem is that we're missing an augmentation from interface Headers {
[Symbol.iterator](): IterableIterator<[string, string]>;
/**
* Returns an iterator allowing to go through all key/value pairs contained in this object.
*/
entries(): IterableIterator<[string, string]>;
/**
* Returns an iterator allowing to go through all keys of the key/value pairs contained in this object.
*/
keys(): IterableIterator<string>;
/**
* Returns an iterator allowing to go through all values of the key/value pairs contained in this object.
*/
values(): IterableIterator<string>;
} I think I can fix this by adding a graft for that specific interface and use declaration merging to get the right type definition in the cross-fetch index.d.ts. |
Awesome! Waiting for the merge 👍 |
Fix released on |
@lquixada This is still happening for me on |
🤦 Sorry again - I was trying to quickly think of a way to fix this problem and I failed to really internalize the problem before proposing a solution. I've got a new approach that I think will really work. I'll open a new PR shortly, including how I've tested it against the code sample in this issue. |
lib.fetch.d.ts includes all type definitions from the dom and dom.iterable libs which were reachable from the original cross-fetch index.d.ts file: ``` git checkout 7b19cda -- index.d.ts ``` lib.fetch.d.ts was generated with the following command: ``` cat <<EOF > .ts-graftrc.yaml \ && npx ts-graft@2.0.0-1 \ && rm .ts-graftrc.yaml \ grafts: - source: index.d.ts output: lib.fetch.d.ts include: - dom - dom.iterable EOF ``` index.d.ts was then updated to its new state and verified with the following command: ``` npx tsc --lib ES6 index.d.ts ``` Issue lquixada#95 was validated as follows: ``` cat <<EOF > test.ts \ && npx tsc --target ES6 --moduleResolution node --noEmit test.ts \ && rm test.ts import fetch from "./"; export const customFetch = ( input: RequestInfo, init: RequestInit, ): Promise<Response> => { let url = ""; url += input; return fetch(url, init); }; EOF ``` n.b. consumers must include the dom.iterable lib, which is implied by the ES6 target, lest their globals lack the required members defined by dom.iterable.
lib.fetch.d.ts includes all type definitions from the dom and dom.iterable libs which were reachable from the original cross-fetch index.d.ts file: ``` git checkout 7b19cda -- index.d.ts ``` lib.fetch.d.ts was generated with the following command: ``` cat <<EOF > .ts-graftrc.yaml \ && npx ts-graft@2.0.0-1 \ && rm .ts-graftrc.yaml \ grafts: - source: index.d.ts output: lib.fetch.d.ts include: - dom - dom.iterable EOF ``` index.d.ts was then updated to its new state and verified with the following command: ``` npx tsc --lib ES6 index.d.ts ``` Issue lquixada#95 was validated as follows: ``` cat <<EOF > test.ts \ && npx tsc --target ES6 --moduleResolution node --noEmit test.ts \ && rm test.ts import fetch from "./"; export const customFetch = ( input: RequestInfo, init: RequestInit, ): Promise<Response> => { let url = ""; url += input; return fetch(url, init); }; EOF ``` n.b. consumers must include the dom.iterable lib, which is implied by the ES6 target, lest their globals lack the required members defined by dom.iterable.
I guess the issue should be reopened until the fix has been merged? More people will stumble upon this |
lib.fetch.d.ts includes all type definitions from the dom and dom.iterable libs which were reachable from the original cross-fetch index.d.ts file: ``` git checkout 7b19cda -- index.d.ts ``` lib.fetch.d.ts was generated with the following command: ``` cat <<EOF > .ts-graftrc.yaml \ && npx ts-graft@2.0.0-1 \ && rm .ts-graftrc.yaml \ grafts: - source: index.d.ts output: lib.fetch.d.ts include: - dom - dom.iterable EOF ``` index.d.ts was then updated to its new state and verified with the following command: ``` npx tsc --lib ES6 index.d.ts ``` Issue #95 was validated as follows: ``` cat <<EOF > test.ts \ && npx tsc --target ES6 --moduleResolution node --noEmit test.ts \ && rm test.ts import fetch from "./"; export const customFetch = ( input: RequestInfo, init: RequestInit, ): Promise<Response> => { let url = ""; url += input; return fetch(url, init); }; EOF ``` n.b. consumers must include the dom.iterable lib, which is implied by the ES6 target, lest their globals lack the required members defined by dom.iterable.
@Jauminha yeah, makes sense. I'm still working on this though! |
@Jauminha just released an alpha version. can you try your code with |
This does not work at all now, because fetch is now a type only and cannot be used as a value/function anymore. |
@iCrawl hi, can you try again with |
Sorry, email notifications went into spam. |
@lquixada was there a problem with the The changes you made put us nearly full circle where importing cross-fetch pollutes the globals with all the types that are in But, server app developers get incorrect type checking feedback. For example, this should not compile without using the dom lib, but it does because the compiler finds a global type definition for Request: import fetch from "cross-fetch";
const req = new Request("http://example.com"); |
@jstewmon I feel the issue we're trying to address here is the conflict reported by @Jauminha regarding Regarding the code you've mentioned, not sure why it should not compile. In Typescript, global types are a valid way to provide typing. import fetch from "cross-fetch";
const req = new Request("http://example.com"); The new That being said, I'm not saying that the current approach ( |
In the example, I used
This requires separate type definition files. The global vars and types should be declared in |
@jstewmon interesting approach! Do you feel we should open a new issue for that? |
I would say this has been a rather tricky issue to sort out, and this discussion has revealed much of the nuance in addressing it properly, so I lean towards keeping the details consolidated here. But, I don't think the choice has much consequence either way, so if you prefer a new issue, that's fine too. |
thanks all! @jstewmon yeah I agree it's a tricky issue. I've released a new version so everyone gets the compilation error solved. Let's open a new issue/PR to address the global pollution and the polyfill case! Closing this one for now. |
(First of all thanks for this amazing package!)
We are using cross-fetch to use the same client calls to our APIs from other APIs and any running application.
For our infrastructural needs, we created a small
customFetch
function on top of thefetch
function so we could change the URL if acloud
parameter is passed or not:After updating to version 3.1.0 our code started to throw the following error:
I inspected the types from both
node_modules/typescript/lib/lib.dom.d.ts
andnode_modules/cross-fetch/lib.fetch.d.ts
and I see no difference apart from this:Hope you can shed some light on this.
Thanks for your time!
The text was updated successfully, but these errors were encountered: