Skip to content
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

Merged
merged 33 commits into from Mar 23, 2022
Merged

fix(deps): update undici to 4.x #8842

merged 33 commits into from Mar 23, 2022

Conversation

janpio
Copy link
Member

@janpio janpio commented Aug 20, 2021

Fixes #6564
Fixes #6899
Fixes #6925

@janpio janpio mentioned this pull request Aug 20, 2021
@janpio janpio changed the title fix(deps): update unidici fix(deps): update unidici to 4.x Aug 20, 2021
@janpio janpio changed the title fix(deps): update unidici to 4.x fix(deps): update undici to 4.x Aug 20, 2021
@janpio
Copy link
Member Author

janpio commented Aug 20, 2021

Available for manual testing as 2.30.0-integration-undici-4.2

@Jolg42
Copy link
Member

Jolg42 commented Aug 23, 2021

Note: we founds that undici was using Blob https://github.com/nodejs/undici/search?q=require%28%27buffer%27%29&type=code which was only added with Node v15.7.0 https://nodejs.org/docs/latest-v16.x/api/buffer.html#buffer_class_blob (Node PR nodejs/node#36811)

We need to make sure this doesn't impact our supported versions of Node (12, 14)

pnpm-lock.yaml Show resolved Hide resolved
packages/cli/helpers/build.js Outdated Show resolved Hide resolved
pnpm-lock.yaml Show resolved Hide resolved
packages/client/helpers/build.ts Outdated Show resolved Hide resolved
packages/client/helpers/build.ts Outdated Show resolved Hide resolved
packages/client/helpers/build.ts Outdated Show resolved Hide resolved
Copy link
Member

@Jolg42 Jolg42 left a 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 💚

@Jolg42
Copy link
Member

Jolg42 commented Jan 12, 2022

This PR is current blocked because the following action job times out CI / client (library, ubuntu-latest, 16) (pull_request) Cancelled after 25m

Some investigation might be needed there first, what I found earlier was that something gets really slow during tests.
Example:
https://github.com/prisma/prisma/runs/4608802724?check_suite_focus=true#step:9:1493

 PASS src/__tests__/integration/happy/binary/test.ts (34.847 s)
  ✓ binary (34030 ms)

vs on main branch

https://github.com/prisma/prisma/runs/4605713109?check_suite_focus=true#step:9:1047
PASS src/__tests__/integration/happy/binary/test.ts (5.121 s)
  ✓ binary (4215 ms)

@millsp saw the heap size getting big too, so that might be linked.

@juanzgc
Copy link

juanzgc commented Mar 13, 2022

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
Which is currently preventing me from using Prisma in Turborepo as a package

@vincent-thomas
Copy link

I have an issue with _http_common and I think this pr is going to fix that problem! Error here:

ERROR in ./apps/thunderbolt/prisma/client/runtime/index.js 27999:21-44
Module not found: Error: Can't resolve '_http_common' in '[path]\Codebase\apps\[app_name]\prisma\client\runtime'

@millsp millsp removed this from the 3.8.0 milestone Mar 22, 2022
@millsp millsp added this to the 3.12.0 milestone Mar 23, 2022
@millsp millsp merged commit 6fc821f into main Mar 23, 2022
@millsp millsp deleted the integration/undici-4 branch March 23, 2022 13:51
Comment on lines +41 to +64
/**
* 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
// },
// ],
// ])
Copy link
Member

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 ?

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Comment on lines +11 to +13
// because undici lazily loads llhttp wasm which bloats the memory
// TODO: hopefully replace with `import` but that causes segfaults
const undici = () => require('undici')
Copy link
Member

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?

Copy link
Member

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').

Copy link
Member Author

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?

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet