[💡 Feature]: Support configuring NODE_OPTIONS for ChromeDriver separately from NODE_OPTIONS for WDIO itself

[tanin47]

Is your feature request related to a problem?

Here's the background: webdriverio-community/wdio-electron-service#331

tldr: we were stuck in getting Electron (dev mode, not prod) to start within WDIO. We've figured that the root cause is because NODE_OPTIONS was set on ChromeDriver. The NODE_OPTIONS (intended for WDIO) happens to cause issue in Electron.

Specifically, WDIO sets NODE_OPTIONS=' --loader ts-node/esm/transpile-only --no-warnings' (ref), which is carried over to ChromeDriver and, thus, Electron.

To verify the impact of this env, we can run: NODE_OPTIONS=' --loader ts-node/esm/transpile-only --no-warnings' ./node_modules/.bin/electron in Terminal, and Electron will crash.

Describe the solution you'd like.

We want to be able to to configure NODE_OPTIONS for ChromeDriver separately from the NODE_OPTIONS for WDIO.

Today NODE_OPTIONS for WDIO is carried over to ChromeDriver; in turn, it is carried over to Electron (dev mode), and Electron crashes because of it.

Here's the line that we want to inject NODE_OPTIONS only for ChromeDriver: https://github.com/webdriverio/webdriverio/blob/main/packages/wdio-utils/src/node/startWebDriver.ts#L86

We want to change it to something like:

driverProcess = cp.spawn(chromedriverExcecuteablePath, driverParams, { env: {...process.env, NODE_OPTIONS: configured_node_options } })

I would also consider adding shell: true, so it closely resembles when the Electron is started directly from command line.

Describe alternatives you've considered.

We could just filter out NODE_OPTIONS altogether as well like:

driverProcess = cp.spawn(chromedriverExcecuteablePath, driverParams, { env: { ...process.env, NODE_OPTIONS: null } })

This also might be preferable because it's more minimal, and we currently don't have a reason to set NODE_OPTIONS for ChromeDriver/Electron.

Additional context

We are trying to get wdio-electron-service to support testing against Electron (dev mode), not just prod mode.

Electron (prod mode) doesn't have the same problem because the prod mode forbids NODE_OPTIONS (ref).

cc @goosewobbler @christian-bromann

Code of Conduct

• I agree to follow this project's Code of Conduct

[christian-bromann]

Today NODE_OPTIONS for WDIO is carried over to ChromeDriver; in turn, it is carried over to Electron (dev mode), and Electron crashes because of it.

Can you be more specific on this section? I don't quite get why certain environment variables available when starting Chromedriver cause Electron to crash.

I would also consider adding shell: true, so it closely resembles when the Electron is started directly from command line.

How is starting Electron related to starting Chromedriver?

[tanin47]

Thank you.

How is starting Electron related to starting Chromedriver?

ChromeDriver starts Electron, and I think the shell env is likely carried over to Electron when ChromeDriver starts Electron, but I don't have a way to confirm this.

I also added in the below to the post:

Specifically, WDIO sets NODE_OPTIONS=' --loader ts-node/esm/transpile-only --no-warnings' (ref), which is carried over to ChromeDriver and, thus, Electron.

To verify the impact of this env, we can run: NODE_OPTIONS=' --loader ts-node/esm/transpile-only --no-warnings' ./node_modules/.bin/electron in Terminal, and Electron will crash.

[christian-bromann]

Thanks for clarifying! I think the best solution would be to just filter out NODE_OPTIONS as you mentioned in your alternative approach. Until we don't really have a reason why someone would need to control extra env vars for Chrome/Electron we shouldn't add any complexity.

Any contributions would be appreciated.

[wdio-bot]

Thanks for reporting!

We greatly appreciate any contributions that help resolve the bug. While we understand that active contributors have their own priorities, we kindly request your assistance if you rely on this bug being fixed. We encourage you to take a look at our contribution guidelines or join our friendly Discord development server, where you can ask any questions you may have. Thank you for your support, and cheers!

[tanin47]

Sounds good. I'm happy to make the change!