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) |
Jolg42
left a comment
There was a problem hiding this comment.
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.
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.
Should we remove this then in a follow up PR?
There was a problem hiding this comment.
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.
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.
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.
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.
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