Improve support for passing AbortSignal

Three things I think could improve working with signals.

1. I’m getting the following type error: Type 'AbortSignal' is missing the following properties from type 'AbortSignal': reason, throwIfAbortedts.

   While Masto uses AbortSignal types from node-fetch, my app uses AbortSignal type from lib.dom since the target is a browser (I also can’t pass Headers due to the same type conflict).

   FWIW I found https://www.npmjs.com/package/undici to have better API compatibility with the browser compared to node-fetch.

2. Make it easier to set a signal for the session: login({ url, accessToken, signal }).

3. Make it easier to set a signal for a specific request.

   This is not a common use case, I don’t think it’s worth adding that option to every API request, but some way of cloning the client with a different signal + access token.

[assaf]

I’d rather prefer adding a second argument that specifies a RequestInit to every method from repositories.

I thought that would be too complicated, but I’d rather have an options argument on each request. That’s easier than dealing with login.

I don’t think it should be RequestInit though. RequestInit includes too many things that I expect the Masto API to ignore — HTTP method, request body, content type, etc. I think it should be a subset of properties (headers, signal, what else?)

In Node.js newer than 18, there’s fetch API in global so we use it by default.

Node 18 ships with undici (https://nodejs.org/en/blog/announcements/v18-release-announce/#fetch-experimental).

You may wonder why we don’t use types provided by lib-dom.

Not really. I only use lib-dom in code that runs in the browser/edge servers, and @types/node in code that runs on Node. The problem with node-fetch is that it’s incompatible with both.

would recommend you cast the value you provided for time being.

Another option is for the Masto API to use W3C types and then cast those to node-fetch behind the scenes as an implementation detail.

[neet]

I’m not saying you’re wrong. I determined that it was the comprehensive and the simplest way to cover use cases by the lowest maintenance cost because even if I restrict functionality by my decision I cannot handle one feature request after another! I hope you understand🙏