../support/util.js is an AMD module, you'll need to load the plugin using an AMD loader for it to be able to require util.js since the Node loader doesn't understand AMD modules (there's no define in the global scope in Node by default).
UnknownError: [POST http://localhost:4444/wd/hub/session / {"desiredCapabilities":...] Misconfigured -- Sauce Labs Authentication Error.
You used username 'None' and access key 'None' to authenticate, which are not valid Sauce Labs credentials.environments for this...
I'm surprised that there isn't a waitFor command, and only waitForDelete. In theintern source, in Session.ts, I see this comment
// TODO: Timeouts are held so that we can fiddle with the implicit wait
// timeout to add efficient `waitFor` and `waitForDeleted` convenience
// methods. Technically only the implicit timeout is necessary.I'm assuming this means that waitFor is indeed not yet implemented. Is there a different method that I'm overlooking that would wait for an element to show up with timeout?
waitForDelete, it doesn't seem complicated to derive waitForimplementation. If I was to do that, what is the way to register it so it's available as one of the regular commands? That is, so I could do something like this.remote.waitFor() in my suites?
afterEach should work. It's possible that if the afterEach is synchronously throwing an exception (say, because it's using unavailable browser APIs in Node) it might be failing (which would be bad).
waitForDeleted seems to have default timeout of 0, meaning it fails right away even if element is not present on page. Is this by design, or something wrong in my env?
waitForDeleted waits for an element to not be present. It internally sets the find timeout to 0 for that to work (otherwise the internal find call would wait for the full timeout before deciding that an element wasn't present). If the element isn't present to begin with, waitForDeleted should succeed.
setTimeout('implicit', 1000) before waitForDelete, it always bails before it even checks if element is present as originalTimeout is 0https://github.com/theintern/leadfoot/blob/master/src/lib/waitForDeleted.ts#L44
waitForDeleted, though -- waitForDeleted always sets the implicit timeout to 0 when it's running, then restores it when the call is finished. If you're seeing an error specifically in the waitForDeleted call, the issue may be that the code is seeing an unexpected error. It expects to see a NoSuchElement error -- that's how it knows when to complete. If the find call throws some other error when an element isn't, that would be an issue.
What I was getting hung up on is that waitForDeleted looks at the existing implicit timeout to know for how long it should run for before throwing an error, right?
if that's 0 by default, and your computer is a bit slow/there is a bit of a hiccup between startTime = Date.now(); and if (Date.now() - startTime > originalTimeout), it means waitForDeleted will throw a timeout right away without even calling find once. This happens intermittently for me if i don't setTimeout('implicit') explicitly to something > 0 :)
So, the last question being, is there a good place to set implicit timeout "globally", or do we just need to remember to set it in every suite?
then callback, like https://www.sitepen.com/blog/command-helpers.