wdio-electron-service does not work when contextIsolation is false

[distributev]

which, most likely, it is still true when rephrased like ' wdio-electron-service cannot be used for most of the existing (big) projects' or
'wdio-electron-service can be used only on new electron projects'

If I try to use wdio-electron-service with contextIsolation: false, I get an error like 'contextBridge needs contextIsolation to be true' and nothing works.

This is happening because the below code uses contextBridge

https://github.com/webdriverio-community/wdio-electron-service/blob/main/src/preload.ts

But if I put contextIsolation: true for getting wdio-electron-service to work I get another error like 'require function not defined' and nothing works. This is happening because I have an existing project where the require function is needed and this project cannot be easily updated as per the latest Electron security best practices (this will be done but it will take a longer period of time to migrate all the existing code).

I understand that the newer versions of Electron, for security reasons, strongly recommends having contextIsolation:true and this is good for new projects but for older and bigger projects it takes more effort to update all the existing code which means that many times people will use contextIsolation:false for such projects.

I believe that wdio-electron-service should work no matter if contextIsolation:true or contextIsolation:false since your library should enable people to use webdriver.io in electron no matter if contextIsolation:true or contextIsolation:false (people will use this flag not because they want to but because for existing projects, they have no other choice).

[goosewobbler]

@distributev Thanks for your request, however I have limited time to maintain this service and whilst I am sympathetic to legacy uses of Electron - contextIsolation has been defaulted to true in Electron since v12 and the Electron security guidelines exist for a reason. I'm happy to accept PRs which address this concern as long as they cover both use cases, which should be forthcoming fairly soon if as you say, "most of the existing (big) projects" are explicitly switching this security feature off.

[goosewobbler]

This issue may be solved with #308