-
Notifications
You must be signed in to change notification settings - Fork 301
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
Node.js compat — Request body/Response can not be initialized with a Readable #2746
Comments
Just a comment to say I think we should only do this in node compat mode. That's all we need it for – and that reduces the surface area for issues – especially if ppl start relying on it in non-Node contexts |
Also, while we're at it – should we throw for any non-supported type passed as the body? Seems we're calling .toString on it if we don't recognise it (would be my guess?). Not sure if that's the spec – if not, might help people track down issues a bit easier. Would need a compat flag though in case anyone was relying on that. |
Keep in mind that supporting
Coercing to a string is required by the spec. We could potentially warn folks but our current behavior here matches the standard and other runtimes. |
Can you explain “even in Node.js compat mode”? That’s all the ask is here.
Sent from Gmail Mobile
…On Thu, 3 Oct 2024 at 2:25 AM, James M Snell ***@***.***> wrote:
Keep in mind that supporting AsyncIterable<Uint8Array> and
Iterable<Uint8Array> as the body are non-standard extensions that I
really wish undici hadn't implemented unilaterally but they do make sense.
Given that they are non-standard, I don't think we should support these
yet, even in Node.js compat mode but should instead first go to WHATWG with
a proposal to add AsyncIterable and Iterable to the spec.
... while we're at it -- should we throw for any non-supported type passed
as the body? Seems we're calling .toString on it if we don't recognise
Coercing to a string is required by the spec. We could potentially warn
folks but our current behavior here matches the standard and other runtimes.
—
Reply to this email directly, view it on GitHub
<#2746 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACZ2QG7OUDW7EOLULEOZDLZZQNBDAVCNFSM6AAAAABOPFQ6BSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBZGA4TMMZSGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
What’s the recommended route to take in the meantime?
Without this we need some way of implementing this behaviour – otherwise certain packages will just not run. Is the suggestion to monkey-patch Request/Response? Do we have a nice/recommended way of doing that?
… On 3 Oct 2024, at 7:46 AM, James M Snell ***@***.***> wrote:
Request and Response are web platform standard APIs. Even in Node.js extending the behavior of web standard APIs in non-standard ways is strongly frowned upon and typically we wouldn't have accepted this kind of variance but it just kind of snuck in. Given that adding this for nodejs_compat would introduce a non-standard variance in behavior of an otherwise mostly standard API, not to mention complicating the implementation of the API a bit, I'd prefer to hold off and see if we can get it added to the standard first.
—
Reply to this email directly, view it on GitHub <#2746 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZ2QGULW4PM2VGX4PAHELZZRSSFAVCNFSM6AAAAABOPFQ6BSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBZG42DQMRUHE>.
You are receiving this because you commented.
|
Can't we re-use
That's something we could bake into unenv. But then users opting out of unenv would see a different behavior |
Yes, absolutely. Instead of passing the Node.js
I would likely choose the first option as it carries the least overhead. |
@jasnell is this something you can take on? I agree that this should be gated behind nodejs_compat flag. The first option sounds good to me, but I don't have strong opinions here except for that without any compat flags we should stick to standards. From @pi0, this seems relevant: denoland/deno#24849 |
Not quite sure what you're asking for @IgorMinar ... the runtime already supports using either the |
I think the question is: Does the runtime team plan to implement Regardless of WHATWG this is implemented in Node and must be supported in If there is no concrete plan, it can be done in Thanks! |
If it is added to the standard, yes. When it is added. I would prefer not to implement it prior to then. |
That's quite clear - we should implement this in unenv. One last question for my understanding: let's imagine |
There will always be limitations to workerd being really Node.js compatible which is why we've gone with the hybrid polyfill model... favoring the use of polyfills to fill in gaps where necessary. |
Repro:
Logs:
Node (/undici) have extra support for
AsyncIterable<Uint8Array>
,Iterable<Uint8Array>
, andnull
forBodyInit
Response
can also be initialized with aBodyInit
, i.e.return new Response(bodyInit);
so we should also update the response in the same wayThe text was updated successfully, but these errors were encountered: