[1.11.0] Generate ERD fails on windows

[DRoet]

Hi, as mentioned in https://github.com/keonik/prisma-erd-generator/issues/220#issuecomment-1673759844

I'm on windows and unfortunately the newer version is not working for me. I did notice that the SVG gets generated if I manually run the mmdc command without the -p PUPPETEERCONFIG flag.

There is a difference in \Temp\PuppeteerConfig.json for me: v1.8.0:

{"logLevel":"warn"}

v1.11.0:

{"logLevel":"warn","executablePath":"/usr/bin/chromium-browser","args":["--no-sandbox"]}

My guess is that the executablePath is incorrect and is not needed when running this package against a windows install. It seems related to https://github.com/keonik/prisma-erd-generator/commit/6a619649bd47f46b0e4583bcb670f1756cdeec0c and not the v5 upgrade directly. The default puppeteer launch configuration within mermaid-cli seems to be https://github.com/mermaid-js/mermaid-cli/blob/master/src/index.js#L161C15-L161C15 and not https://github.com/mermaid-js/mermaid-cli/blob/master/puppeteer-config.json

[keonik]

https://github.com/puppeteer/puppeteer/blob/main/README.md#default-runtime-settings

I am trying to avoid going down the OS rabbit hole of puppeteer problems. The link above says if an executable is provided it looks for it. So I'm assuming Windows does not include a packaged Chromium instance by default like Mac and Linux. Is that safe to assume? If so, I need to add a third statement checking if the user has a windows machine similar to my doing for arm64 MacOS users.

[DRoet]

Puppeteer on Windows does include a packaged chromium instance located in:

%USERPROFILE%\\.cache\puppeteer\chrome\win64-1095492\chrome-win

That is why it was working in the older version when executablePath was undefined, since Puppeteer would do the work and correctly lookup the binary. Perhaps the executablePath only needs to be set for M1/M2 setups and the default can be changed back to undefined instead of /usr/bin/chromium-browser

[keonik]

Gotcha. So Windows uses the packaged chromium under puppeteer. Hopefully, its safe to assume all Windows machine folks will point to that instance so I can keep the default path for Linux and Mac. I'll work on this asap. For now, check to see if you can work around it by setting the path in the puppeteer config to null.

[github-actions[bot]]

:tada: This issue has been resolved in version 1.10.0-alpha.6 :tada:

The release is available on:

• npm package (@alpha dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[DRoet]

Hi @keonik thank you for looking into this.

I can confirm that the ERD generation is now working with 1.10.0-alpha.6. However when I run the generate command three separate powershell windows shows up for about 1 second displaying the following error:

ERROR:command_buffer_proxy_impl.cc(128)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer.

The powershell window closes itself after so it's not a huge deal for me personally. Just figured I would let you know. It seems related to the args: ['--no-sandbox'] option and GPU hardware acceleration. If I remove --no-sandbox from the configuration the error dissapears. perhaps no sandboxing is only needed for Linux/Mac?

Again not a huge issue, but might confuse some users after running npm install and generating the ERD

[keonik]

@DRoet I can remove that as well.

[keonik]

Pushed up to v1.11.1 without the args attached to any config but darwin arm64

[github-actions[bot]]

:tada: This issue has been resolved in version 1.12.0-alpha.1 :tada:

The release is available on:

• npm package (@alpha dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[DRoet]

Can confirm that it is now working, thank you for looking into this! ❤️