Can `browser` reference not to be hard coded?

[pillsilly]

https://github.com/webdriverio/expect-webdriverio/blob/2c8efefcce1b50b1b62abc7af1f1eed3d5cf7f9d/src/matchers/element/toHaveAttribute.ts#L26

As seen, the above implementation assumes the lib must be used in a supported test runner(which has "global.browser" by default) but in fact my test runner (protractor) has that reference taken already.

Would it be reasonable if we open a path for such case? So that a user can assign the browser instance he/she wants.🤔

Also, I wonder how much "default" global variable names are being used here so that I can know how difficult would it be to make a configurable implementation

[christian-bromann]

Thanks for reporting!

Can you explain a bit your situation? Are you using Protractor and WebdriverIO together?

[pillsilly]

Thanks for reporting!

Can you explain a bit your situation? Are you using Protractor and WebdriverIO together?

I am aware of https://webdriver.io/docs/protractor-migration but due to our complex architecture, I'm trying a solution aside of that and everything so far is fine until I tried to add expect-webdriverio.

As you might know, the protractor use "browser" as well in global scope, so when I inspect the code quoted above when running it.

I found it's actually the reference of protractor's "browser" -- while we're expecting it to be wdi's, right?

[pillsilly]

just an example

diff --git a/src/types/expect-webdriverio.d.ts b/src/types/expect-webdriverio.d.ts
index 69c637f..92a69ad 120000
--- a/src/types/expect-webdriverio.d.ts
+++ b/src/types/expect-webdriverio.d.ts
@@ -1 +1 @@
-../../types/expect-webdriverio.d.ts
\ No newline at end of file
+../../types/expect-webdriverio.d.ts
diff --git a/src/types/some-expect.d.ts b/src/types/some-expect.d.ts
index 45e8a71..72644a5 100644
--- a/src/types/some-expect.d.ts
+++ b/src/types/some-expect.d.ts
@@ -3,6 +3,7 @@
  * INTERNAL USAGE ONLY
  */

+
 declare namespace NodeJS {
     interface Global {
         expect?: SomeExpectLib;
diff --git a/src/utils.ts b/src/utils.ts
index 5b5b305..64a9324 100644
--- a/src/utils.ts
+++ b/src/utils.ts
@@ -19,6 +19,8 @@ const waitUntil = async (condition: () => Promise<boolean>, isNot = false, {
     wait = DEFAULT_OPTIONS.wait,
     interval = DEFAULT_OPTIONS.interval } = {},
 ): Promise<boolean> => {
+    const _browser = config.wdiBrowserRef || browser;
+
     // single attempt
     if (wait === 0) {
         return await condition()
@@ -27,7 +29,7 @@ const waitUntil = async (condition: () => Promise<boolean>, isNot = false, {
     // wait for condition to be truthy
     try {
         let error
-        await browser.waitUntil(async () => {
+        await _browser.waitUntil(async () => {
             error = undefined
             try {
                 return isNot !== await condition()
diff --git a/types/expect-webdriverio.d.ts b/types/expect-webdriverio.d.ts
index 72a0ffb..988e754 100644
--- a/types/expect-webdriverio.d.ts
+++ b/types/expect-webdriverio.d.ts
@@ -1,7 +1,10 @@
+import { Browser } from "webdriverio/build/types"
+
 declare namespace ExpectWebdriverIO {
     function setOptions(options: DefaultOptions): void

     interface DefaultOptions {
+        wdiBrowserRef: Browser<'async'>
         /**
          * time in ms to wait for expectation to succeed. Default: 3000
          */

[christian-bromann]

Yeah, this library expects browser to be a global variable that points to the WebdriverIO instance. We already have an issue for this in #237 - which is why I am going to close this one - where we can continue to discussion started there.

What I would recommend though is to first work on a WebdriverIO setup that mimics what you have right now for Protractor and then port tests over file by file. That sounds to be more reasonable than trying to run both frameworks in a single test file.