For some reasons my email reply to issues/PRs are no longer getting through, so add it again:

• This PR has the same level of risk as removing browser export, please make sure at least 3 reviewers have approved it before merging.

• The timeout signal module appear to be the main alternative after deprecating timeout, I suggest moving it to node-fetch org and adding extra npm owners to ensure maintenance.

• The documentation shouldn't just say we deprecate it because of "non-standard", while this is a part of our reasoning, the main reason is something like "Abort Signal offers more finegrained control of timeout, and is standardized in Fetch spec. For convenience, we provide a timeout signal as a simple replacement for users upgrading from v2".

Should #810 be merged first, to keep changes to typing in this PR?

Again, here Coveralls Coverage decreased by -0.01%

@NotMoni This is not a big deal here, once we merge #829 the coverage will raise, as it also includes the updated ignore comments.

We might want to try and bring the coverage back to a full 100% soon in a separate PR.

@tinovyatkin Yes, I think so.

@NotMoni This is not a big deal here, once we merge #829 the coverage will raise, as it also includes the updated ignore comments.

We might want to try and bring the coverage back to a full 100% soon in a separate PR.

Yea, coverage to 100% will be good to do.

This will be a very painful breaking change for may libraries that depends on node-fetch, as it will require to introduce abort-controller as a dependency. Maybe we should just deprecate timeout in 3.0 and remove it in the next major?

@tinovyatkin It would, but only for people, who actually want to use this feature. So the others would benefit, as the "core" node-fetch package would not include it.

I agree that this is a breaking change, so more discussion is probably a good thing.

cc @node-fetch/core

@xxczaki I mean, I believe that it will be too hard to implement vs a desire to just stick with 2.x version. For example, gaxios by Google is using node-fetch and even has abort-controller as a dependency, but only to declare types:
https://github.com/googleapis/gaxios/search?q=abort-controller&unscoped_q=abort-controller

So, now they will need to decide whether to drop timeout parameter on their side and release new major of gaxios or implement their timeout via AbortSignal or just pin the dependency on the latest 2.x version of node-fetch until they will have the bandwidth to deal with it.

gaxios engine requirement is already 10.x, so, actually that will be the only breaking change for them...

Deprecating (with process.emitWarning) this parameter in 3.0 will allow us to get customer feedback before moving forward - I believe it's a Node.JS way for matured libraries.

pls fix merge conflict with TS Typing before we can merge

cc/ @Richienb

This will be a very painful breaking change for may libraries that depends on node-fetch, as it will require to introduce abort-controller as a dependency

For what it's worth, I use node-fetch heavily in the @octokit libraries, and I allow to pass a signal option to each request, which can be set using an AbortController instance. I do not need to add abort-controller as a dependency, it's up to the integrator to add that if they need to.