⚠️ Call for Maintenance ⚠️

[christian-bromann]

The WebdriverIO team does no longer need this package due to its recent improvements when it comes to driver management. Since this package still has a substantial amount of usage and might still be useful for the some out there we are happy to give this package away and transfer its ownership to anyone who is interested taking on maintenance of this package.

Please let us know in this thread.

Thank you!

[harsha509]

Hi @christian-bromann ,

Am interested in maintaining it...!

Thanks, Sri

[udarrr]

Hi @christian-bromann

I am into it I can rewrite it to typescript and proceed with maintaining Because the tool still useful even with last changes, due to some constraints with wdio standalone and remote modes.

Best regards

[christian-bromann]

due to some constraints with wdio standalone and remote modes.

Can you explain what you mean by that? If there is something we can do to so that you do not need to use this package anymore, please let us know.

[christian-bromann]

This is blocked by https://github.com/openjs-foundation/cross-project-council/issues/1133

[udarrr]

due to some constraints with wdio standalone and remote modes.

Can you explain what you mean by that? If there is something we can do to so that you do not need to use this package anymore, please let us know.

Ok let me explain. Generally for starting tests we should be aware about current version our browser that determine version of chromedriver. The most issues are when chrome browser is updated but version of chromedriver still don't exist for the version and solution for that just using last version chromedriver from major version of browser. Not so important installing new browser version. That's why the tool just provide us last available drivers version like it was and for most cases those are enough.

Also in a case of electron testing for us necessary just chromedriver instance and version of chromedriver depends on electron version. After last updates to the tool we can create config for the electron chromedriver version and proceed with the testing. I'm not convinced it's available in wdio8 currently.

[christian-bromann]

@udarrr the latest WebdriverIO (testrunner and standalone mode) manages Chrome and Chromedriver for you, see https://webdriver.io/blog/2023/07/31/driver-management. If you do Electron testing, the Electron service also manages the Chromedriver install. This is the reason why I don't think this package is in anyway useful for WebdriverIO anymore.

[udarrr]

@udarrr the latest WebdriverIO (testrunner and standalone mode) manages Chrome and Chromedriver for you, see https://webdriver.io/blog/2023/07/31/driver-management. If you do Electron testing, the Electron service also manages the Chromedriver install. This is the reason why I don't think this package is in anyway useful for WebdriverIO anymore.

I see, it has sense. It's available since wdio 8.14 but there are a lot of people who are still using wdio7 for some reason. And i one of the person)

[christian-bromann]

for some reason

What are the reasons?

[udarrr]

legacy projects even still with wdio6, and migration require affords. Who knows what are going to be broken after migration. For new projects wdio8 is good choice but for old one not yet or not for all.

[udarrr]

@christian-bromann did you see that wdio6 still are being used? regarding downloads for last week, with wdio7 the same

[mikesalvia]

@christian-bromann So I have a particular use case that would warrant this continuing to be a part of WebDriver.IO even if it isn't provided as a service. Unless there is a better way to achieve this, which I would be interested in.

Not too long ago we created Magic Link for our login flow...

1. Via Appium on an Android device a magic link request is triggered.
2. Magic link is obtained via a Gmail account using wdio-gmail-service
3. Then a Chrome instance is spun up in steps to visit this link.
4. We switch back to the Android device to verify login.

Because we are connecting outside of the test runner life cycle ONLY for a single step we are using selenium-webdriver.

Having @wdio/selenium-standalone-service makes providing Selenium to those "out-of-band" session creations is much better then having to instrument selenium-standalone myself inside of my wdio.conf.ts.

[christian-bromann]

Because we are connecting outside of the test runner life cycle ONLY for a single step we are using selenium-webdriver.

Can you elaborate why you have to use selenium-webdriver for creating a session instead of using webdriverio? There is nothing webdriverio couldn't do.

[mikesalvia]

Can you elaborate why you have to use selenium-webdriver for creating a session instead of using webdriverio? There is nothing webdriverio couldn't do.

I was under the impression you needed to start all WebDriver.IO controlled session via capabilities before beforeSession.

Also, thought running browser.newSession({ browser: "chrome" }) would destroy older session.

[christian-bromann]

You can start a standalone session at any time even during the test by importing webdriverio.

[mikesalvia]

I will try that... So basically something like webdriverio.newSession({})?

[christian-bromann]

import { remote } from 'webdriverio'

const newBrowser = await remote({ ... })

See more here: https://webdriver.io/docs/setuptypes#standalone-mode

[mikesalvia]

You can start a standalone session at any time even during the test by importing webdriverio.

When you are right you are right...

[seanpoulter]

This is blocked by openjs-foundation/cross-project-council#1133

Mind if I drive things forward while we're blocked?

[christian-bromann]

Mind if I drive things forward while we're blocked?

Sure thing.