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
fix(deps): update undici to 4.x #8842
Conversation
Co-authored-by: Joël Galeran <Jolg42@users.noreply.github.com>
Available for manual testing as |
Note: we founds that undici was using We need to make sure this doesn't impact our supported versions of Node (12, 14) |
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.
Thank you for pushing this through the door, it might very well be useful for other wasm projects 💚
This PR is current blocked because the following action job times out Some investigation might be needed there first, what I found earlier was that something gets really slow during tests.
vs on main branch
@millsp saw the heap size getting big too, so that might be linked. |
Is there any news on the state of this PR and whether it is still being blocked 😇 ? I believe this PR would fix the following Issue: #6899 |
I have an issue with
|
4a1e395
to
fb7d30d
Compare
/** | ||
* Example | ||
*/ | ||
// const inlineUndiciWasm = replaceWithPlugin([ | ||
// [ | ||
// /(await WebAssembly\.compile\().*?'(.*?)'\)\)\)/g, | ||
// async (regex, contents) => { | ||
// for (const match of contents.matchAll(regex)) { | ||
// if (match[2].includes('simd') === false) { | ||
// // we only bundle lhttp wasm files that are not simd compiled | ||
// const engineCoreDir = resolve.sync('@prisma/engine-core') | ||
// const undiciPackage = resolve.sync('undici/package.json', { basedir: engineCoreDir }) | ||
// const lhttpWasmPath = path.join(path.dirname(undiciPackage), 'lib', match[2]) | ||
// const wasmContents = (await fs.promises.readFile(lhttpWasmPath)).toString('base64') | ||
// const inlineWasm = `${match[1]}(Buffer.from("${wasmContents}", "base64")))` | ||
|
||
// contents = contents.replace(match[0], inlineWasm) | ||
// } | ||
// } | ||
|
||
// return contents | ||
// }, | ||
// ], | ||
// ]) |
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.
What is this example for @millsp ?
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.
It used to show how to inline wasm when the wasm file is not directly imported. However, in the mean time undici changed how they load the wasm and now puts the wasm contents in a .js file instead of doing a readFileSync
so this is not needed anymore and works well when bundled.
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.
Should we remove this then in a follow up PR?
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.
We can probably trim it a bit, but I'd like to keep an example for how to use replaceWithPlugin
.
// because undici lazily loads llhttp wasm which bloats the memory | ||
// TODO: hopefully replace with `import` but that causes segfaults | ||
const undici = () => require('undici') |
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.
So that's our current workaround for the segfaults for the Binary? any idea why is this happening?
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.
I initially wanted to do () => import('undici')
and I could not understand why this could cause segfaults in jest
and only on CI. So I swapped for () => require('undici')
.
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.
Worth opening a PR again to see if it still happens, and if so maybe point it out to Undici/Node ppl?
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.
I tried this today. I made undici
not to load lazily like it does by re-wrapping it in () =>
. Somehow, their lazy loading of the wasm (ie. on module load) was also causing memory leaks in jest. It would make sense to debug where it segfaults when doing import
instead of require
so that we can report to them.
Fixes #6564
Fixes #6899
Fixes #6925