Stable Fetch

[ronag]

What is left for us to consider fetch stable?

[ronag]

@KhafraDev @mcollina

[mcollina]

I think we would need to make a call on #1203.

[ronag]

Performance is not a significant factor, in my opinion, for stability. I think for most use cases, the existing performance is acceptable. If performance is important you shouldn't be using the fetch api to begin with.

[silverwind]

If performance is important you shouldn't be using the fetch api to begin with.

Performance and Convenience don't have to be exclusive. That's like saying if you want performance, you shouldn't use Node.js/JavaScript/Non-Assembly language 😉.

[ronag]

Performance and Convenience don't have to be exclusive.

I'm not saying that. I'm saying performance is NOT a MUST for a stable release while correctness IS a MUST.

[jimmywarting]

performance is NOT a MUST for a stable release while correctness IS a MUST.

agree,

It would be a different if there is a memory leak due to some performence issue or something else then that is a bug and something that needs to be fixed before calling it stable.

Performence can be dealt with over time

[mcollina]

I think we should provide a way to solve the cookie issue before calling it stable: #1437.

[KhafraDev]

Until whatwg/fetch#973 is added there's not much we can do about cookie headers, otherwise we'll be stuck with a non-spec compliant method that will eventually be removed in favor of getSetCookie anyways. Of course if we implement getSetCookie we also have a problem where any changes done to it before it becomes stable will be a breaking change.

It's currently stuck on getting implementer interest from two browsers.

This should probably be handled by wintercg

[mcollina]

I think fetch without cookies is not really useful.

Apart from that I think we can call in stable in undici and drop the experimental warning in Node.js. I would still leave it experimental there for a bit longer.

[KhafraDev]

Once fetch is stable, would changes to the spec that changed behavior be considered breaking? If so, would there be a new major release of undici for otherwise seemingly minor changes? Ref: #1681

[mcollina]

We should create a policy for this and possibly share it also with the TSC.

My 2 cents is that approved spec changes are not breaking, otherwise Node.js will end up bein significantly behind and we'd end up maintaining too many lines. However we should validate this with the TSC.

[ronag]

There is maybe actually on thing that can be blocking here. Blob and the lack of file system backing.

[KhafraDev]

undici does support third party Blobs, so you could use fetch-blob for blobs backed up by the file system.