-
Notifications
You must be signed in to change notification settings - Fork 562
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
feat: add build for porting fetch to Node.js #1183
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1183 +/- ##
=======================================
Coverage 93.73% 93.73%
=======================================
Files 41 43 +2
Lines 4020 4022 +2
=======================================
+ Hits 3768 3770 +2
Misses 252 252 ☔ View full report in Codecov by Sentry. |
If we do that, it is possible to test it in userland. Just run |
Why are we bundling it? Wouldn't it be simpler to just add it to The best approach would be to use the node core bindings for http_parser. However I'm 100% happy to inline the wasm for now. I would require we use the internal binding for |
core doesn't support relative |
Ah, that's true. Bundling is perfect. |
I see that there are two different wasm builds. Do we need to bundle both? |
I think the wasm version might be faster though? Can’t we look into getting that working somehow? |
Should I look into inlining the WASM code for everyone or only for node core and keep the current behavior for the npm module? |
I think future wise, it would be nice if Node core used a WASM build of llhttp instead of the native one in general. It would be nice to keep the current behavior for the npm module. |
I think you can just bundle the SIMD version. However we might need both for some architecture or in case of a backport. I'm not sure if the wasm simd is available everywhere. |
@targos thank you for your effort on this! |
Here's a Node PR based on this: nodejs/node#41749 |
So, the current state is that both WASM builds are serialized to base64 strings which are exported from two CJS modules (58kb each). I did not keep the current behavior for the npm module because I'm not sure yet how to do it. |
I’m fine with this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Inlining it for everyone would make it easier for other projects that also needs to bundle their dependencies. |
Is this ready to merge? @targos |
If it's fine for you, yes! |
Fixes: #19393 PR-URL: #41749 Refs: nodejs/undici#1183 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Mestery <mestery@protonmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
Thank you. This is amazing. Thanks to everyone who made this happen 💖 |
Hello,
Simd support in V8 has just been recently added to some architectures such as PPC and S390 and even then they are only supported on new hardware (i.e. PPC 9 and above). Running Simd code on older node versions or older hardware will just crash. It would be better to include both versions and fall back to regular Wasm code if Simd isn't supported. I can see this module is is compiled with wasi-sdk: nodejs/llhttp#93 emscripten on the other hand does generate its own Js files and it's patched to handle endianness problems when dealing with Typed Arrays: emscripten-core/emscripten#13413 We are still working around some remaining problems related to its usage on BE machines but in general emscripten might be safer to use. |
We already do this?
Do you have a concrete example? PR welcome! |
Thanks for confirming.
Wasm memory is LE even on BE machines. Typed Arrays however follow the machine byte order. emscripten has been patched (link in my previous comment) to use If emscripten is used then all the generated Js files should also be safe to run on BE. If Js files are being written manually then the developer should make sure Typed Arrays wont cause an endianness problem. |
Wouldn't it be easier to just fix the js code in the few places where the endianess is relevant? |
We could take that approach per project/module (i'm just using llhttp as an example here). We have to make sure no usage of typed arrays is missed and test cases cover all the scenarios otherwise random failures could happen during production runs of a given module. |
In the case of undici I don't think it's that complicated? |
Doesn't seems like its too complex. If Typed Arrays such as this: https://github.com/nodejs/llhttp/blob/main/examples/wasm.ts#L197 |
Fixes: #19393 PR-URL: #41749 Refs: nodejs/undici#1183 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Mestery <mestery@protonmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
Hey, I'm testing
Since these files are now inline, could be possible they are no more necessary to be shipped with the library output? that will be make undici a bit lightweight to install 🙂 |
could you send a PR to remove them? |
Fixes: nodejs#19393 PR-URL: nodejs#41749 Refs: nodejs/undici#1183 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Mestery <mestery@protonmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
Fixes: nodejs#19393 PR-URL: nodejs#41749 Refs: nodejs/undici#1183 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Mestery <mestery@protonmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
Fixes: #19393 PR-URL: #41749 Backport-PR-URL: #42727 Refs: nodejs/undici#1183 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Mestery <mestery@protonmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
* feat: add build for porting to Node.js * inline wasm * Update package.json
Node.js core doesn't support relative require calls, so this change provides a bundles API for Postject, so that it can be used easily in Node.js. Undici too follows the same strategy. Refs: nodejs/undici#1183 Signed-off-by: Darshan Sen <raisinten@gmail.com>
* feat: provide bundled API Node.js core doesn't support relative require calls, so this change provides a bundles API for Postject, so that it can be used easily in Node.js. Undici too follows the same strategy. Refs: nodejs/undici#1183 Signed-off-by: Darshan Sen <raisinten@gmail.com> * fixup! test: bump timeout value from 60000 to 65000 Signed-off-by: Darshan Sen <raisinten@gmail.com> * fixup! test: bump timeout value from 65000 to 70000 Signed-off-by: Darshan Sen <raisinten@gmail.com> * fixup! fix: --output-api-header handling Signed-off-by: Darshan Sen <raisinten@gmail.com> * fixup! refactor: bundling and copying to dist logic Signed-off-by: Darshan Sen <raisinten@gmail.com> * fixup! chore: Error -> TypeError Co-authored-by: David Sanders <dsanders11@ucsbalum.com> Signed-off-by: Darshan Sen <raisinten@gmail.com> Co-authored-by: David Sanders <dsanders11@ucsbalum.com>
* feat: add build for porting to Node.js * inline wasm * Update package.json
* feat: add build for porting to Node.js * inline wasm * Update package.json
In the discussion we had during the mini-summit, it was decided that we would try to include
undici
'sfetch
implementation in Node.js 18.I just started experimenting with it and I figured it would be easier to discuss in a pull request, where we can directly try some things.
The
esbuild
output seems fine (I can push it here, but wanted to avoid too big of a diff), but we obviously have a problem with llhttp/WebAssembly.Before I go too far in the wrong direction, what should we do about it? I can think of two solutions:
undici
that uses the llhttp parser to conditionally use the internal node binding. This is not trivial, as currently the native binding doesn't expose the exact same API thatundici
uses./cc @nodejs/undici