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
v4 Roadmap #1452
Comments
If we break out undici headers and form data into separate packages. Would you consider using that? |
hmm, yea, but they are already broken out into separate packages
i would rather want to see it landing into NodeJS core instead |
Looks like a great list!
|
Blob.stream was added in: v16.7.0 |
Anything I can do to help v4 become a reality? I'm working on a grpc lib and the sooner the whatwg streams are a reality the better that is for me 😊 |
Yes, we are open to whatwg stream in v4, Jimmy will probably lead that effort. We are open to experimental PR on it.
I am not certain fetch is the best API for rpc calls, best make the spec covers all you requirement, as we do intend to follow the spec more closely.
…Sent from my iPhone
On Jan 21, 2022, at 15:48, Chris Kruining ***@***.***> wrote:
Anything I can do to help v4 become a reality? I'm working on a grpc lib and the sooner the whatwg streams are a reality the better that is for me 😊
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.
|
Umh... i would like to finish some issues that are possible to solve before we jump onto the v4 wagon. it's still some few mounts left to v12 goes EOL. and i'm not sure whether or not i want to abandon the v3 just yet. But there could be things we could work on towards making whatwg streams possible to use in some ways. import { Response, Blob } from 'node-fetch'
// i think this works:
const blob = new Blob(['abc'])
await new Response(blob).text() === 'abc'
// but this one dose not
const stream = blob.stream() // returns a web readable stream
await new Response(stream).text() === 'abc' We need to improve the writeToStream to be able to write to node's http.request using whatwg streams, node streams and or using async iterators. Some suggested change could be: /**
* Write a Body to a Node.js WritableStream (e.g. http.Request) object.
*
* @param {Stream.Writable} dest The stream to write to.
* @param obj.body Body object from the Body instance.
* @returns {Promise<void>}
*/
export const writeToStream = async (dest, {body}) => {
if (body === null) return dest.end()
// Body is async iterable (node stream, whatwg stream or any iterable that yields uint8array
for await (const chunk of body) {
dest.write(chunk)
}
}
dest.end() I have tried making a change like this before - but it broke some tests. |
That's actually even better, I am making this lib for the browser, so if node has a spec compliant fetch implementation that is a win for me.
That seems doable, node stream, whatwg stream are both also async iterable. So updating the constructor of |
We can't exactly change the body class to be a whatwg stream or a async iterator in v3 I think the easiest corse of action is to just look in if ( isNodeStream ) body = body
if ( isIterable ) body = stream.Readable.from(body) But we can't just go a head and convert anything that is iterable either... if ( isNodeStream ) body = body
if ( isRedableStreamLike ) body = stream.Readable.from(body) there is also |
I would like to have a I found this one earlier: but it only supports NodeJS v16 We need something that can fall back to web stream polyfill... |
just realized something... I wonder what that means for maybe we should bring in a polyfill for time being... const AbortController = globalThis.AbortController || await import('polyfill') |
I realise this might not be useful at all, but in the off-chance it is: In order to have http2 and async iterables, I implemented a VERY minimal 'version' of this lib myself. feel free to take a peek and steal any code you want from this for the 3.x and 4.x milestones (motivation for a custom implementation: this lib doesn't currently support http2 and fetch-h2 isn't compatible with the types in TS) |
Thx, one thing that would be very useful for the nodejs community: an abstraction on top of http1 and http2, If anyone is willing to take the task, I would love to open a repo at node-fetch org for him/her to lead, perhaps even throw in our open collective donation as bonus :) |
I just discovered that nodejs 18 is getting native fetch support. so, is it worth much to put a lot of effort into this lib still? I have no clue how far node 18 is off yet. but I feel like it's is a massive waist of good effort from the contributors if the work is obsolete in -I am guessing- a couple of months |
I would also like to start using built in node's fetch in v18 |
@agrohs what's your reason for 👎 ? |
|
If all goes to plan, |
Can the pull request #1473 be included in v4? It changes the default value of the |
you might not want to release a new version. Node has built-in fetch @ |
There are things even the NodeJS impl is missing... like parsing application/multipart for instances... Also not everybody can update to NodeJS v18 yet |
I'm quite surprised that node team decided to go with a different implementation |
Is there an official statement on native fetch in node 18 vs this library? Stability 1 (experimental) from the native implementation https://nodejs.org/dist/latest-v18.x/docs/api/globals.html#fetch has my team worried about moving to it, but at the same time, we don't want to move to this if you may be phasing out support in September 2023 when node 16 reaches EOL. |
I would not worry about it to much. their fetch impl is really grate and even more spec compliant then our own. it solves some thing more correctly then what we are doing in the only culprit could maybe be that it dose not support using a own custom http agent or that some compressed responses aren't able to be unpacked [1 2]. one has been resolved in the undici package already by me and have been published to npm already, i guess it takes a tiny bit longer for things to those changes to land in NodeJS core cuz of their release cycle. The other thing could maybe be that you lose the functionality of getting everything that is inherited from Other then that our long term plan is for undici have also imported all our our own test to make sure that undici haven't forgotten anything. few of them are disabled (if you search for one thing i might have planned on doing for v4 is just simply re-export everything from undici (to have node v16 support) where as when v16 reaches EOL we would then just only re-export the builtin instead. at which point it's just a completely worthless thing to have as a dependency. may not even do that either. maybe will just add a deprecation notice when v16 reach EOL in sept.
it might depend on if we are able to find other useful usecases for node-fetch in the feature or what we will do next after this if anything at all... maybe we wanna build a variant that can support cookie jar. progress event, patching |
node-fetch is really great. Although the fetch api has been added since node.js v18, I chose node-fetch because of the need for proxy. This is the necessity of node-fetch. Also, are there any plans to add support for fingerprint, which can be setup with tls/ja3? bless |
General stuff
v3 may have been short lived, cuz of how long time we dragged out on esm.
We already have a milestone for v4 with few issues in it.
NodeJS v12 will soon end its LTS version in April, so i was thinking of dropping support any prior version and remove all the hacks we have around it in the current branch.
I was thinking about setting the lowest supported node version to v14.17.0
not 14.13.1 as we have today that is meant for ESM
why? cuz http.request supports signal in v14.17.0
then we can also use finalizers that got introduced in v14.6.0 and cleanup the response (and the cloned res) when it's forgotten and not consumed
Is there any bug/issue/features we would like to finish or complete before we branch out of v3 and start working on v4?
http.request(url { signal })
.body
to be a whatwg stream^ 14.17.0 || >=16.0.0"
?ReadableStream.prototype.tee
instead.buffer()
#1485size
option (fixes Deprecate size option #1438)cc @bitinn @TimothyGu @jkantr @gr2m @Richienb @ronag @LinusU
The text was updated successfully, but these errors were encountered: