-
Notifications
You must be signed in to change notification settings - Fork 541
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
Ability to externalize WASM was broken #3345
Comments
There is some discussion in the PR after it landed, goal is to add back the parts that were removed but still needed while keeping what was optimized in #3074 |
Yes, we discussed this, I kind of lost track of it. |
Should we revert? @mhdawson how can we test for this in a meaningful way so we don't regress? |
I was talking about that a bit with Richard. I don't know the undici tests well enough to know off the top of my head, but building with the option enabled and validating that the wasm file is were it's expected afterwards was what we thought might work. |
@mhdawson if any of you can drop a PR for this, it would be very useful to prevent further issues. |
Actually it just needs like 5 more lines, I promise I will provide a PR tonight at latest midnight (German Time), |
@Uzlopak do you mean you will include the testing in your PR? |
I will also provide a test. |
@Uzlopak Any updates? |
@Uzlopak just wondering if there is something I can do to help this along? If you have the right way in mind to fix but just don't have time maybe we can get together to do some knowledge transfer and either myself or @richardlau can help out? |
I'm working on this and should be able to open a PR either later today or tomorrow (trying to get a working GitHub Actions flow in place so future regressions can be detected). |
PR: #3421 |
Bug Description
This PR introduced the ability to externalize WASM, which is needed by distros to be able to rebuild all components shipped: #2643
PR #3074 broke this by removing some of the implementation needed.
Reproducible By
Build as specified in the undici CONTRIBUTING.md - https://github.com/nodejs/undici/blob/main/CONTRIBUTING.md#building-for-externally-shared-node-builtins
and validate that the wasm is not in the expected place
Expected Behavior
After building as described in the undici CONTRIBUTING.md - https://github.com/nodejs/undici/blob/main/CONTRIBUTING.md#building-for-externally-shared-node-builtins
the wasm binary should be in the expected place
Logs & Screenshots
Environment
Additional context
The text was updated successfully, but these errors were encountered: