* return the same value of getSession
* chore: update docs and implementation
* remove event stuff
* add type in return
* add AppiumSessionCapabilities type
* update the syntax
* rename
* add test in e2e
* remove unnecessary type
* use fake driver name
* chore: use regext to check session id requirement
* update docs
* add test case
* use match of path-to-regexp
* use another name to avoid conflict
* accept appium prefix for non-session id
* feat: add /appium/sessions, /session/:sessionId/appium/capabilities and deprecated marks will be removed in the future
* add a dymmy implementation
* move entire deprecated endpoints in bottom of each section
* define GET_APPIUM_SESSION_CAPABILITIES and add it to isAppiumDriverCommand
* adds _COMMAND
* remove unnecessary method definition
* move deprecated endpoints
* add temporary implementation
* Revert "feat(appium): Add session signature to all logs (#20202)"
This reverts commit b3f8a47c2d.
* Revert "feat(logger): Add the 'debug' level to the default logger (#20203)"
This reverts commit 7fd9d5f626.
- `core` module is now TS
- `constants` module is now TS
- export missing `W3C_ELEMENT_KEY`
- `JWProxy.command` returns `Promise<unknown>`. deal with it
- updated some type tests
This cap was conflicting with constraints defined in subclasses. Currently, it isn't possible to cleanly "override" constraints. Given `deviceName` is not used anywhere within base-driver's source, this seems like a decent workaround for now.
This seems to fix the bug in #18379. There must be some sort of bug in TypeScript w/r/t `@implements` or maybe even it was not treating `@typedef` as a proper alias. Perhaps it's user error--omitting optional type args in alias-style typedefs may end up making a new type entirely. idk, but this was easier to deal with.
Closes#18379.
* fix(appium): inability to find automationName inside appium:options
we fixed this before but only fixed it in basedriver's createSession, which is not
actually called by Appium's createSession (though maybe it should be)
* test(base-driver): remove appium:options test
* feat(base): add get computed role and label in W3C v2
* add command names
* chore: add type
* chore: use `?` instead of `| null`
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Revert "chore: use `?` instead of `| null`"
This reverts commit 62af5e80ac.
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
The big idea here is:
1. `desiredCapConstraints` should always contain the constraints _for that driver_; it no longer contains the "base" constraints. This is the only thing that really required any logic changes (though they are somewhat spread out). The "merged" constraints object is available via `_desiredCapConstraints`.
2. `Capabilities` and W3C-style `W3CCapabilities` are now _derived from_ constraints. This absolves us (and extension authors) from needing to create an interface describing their capabilities.
3. Changes to caps and constraints now reflect in `DriverOpts` (`this.opts`) in drivers
4. `caps` and `originalCaps` declarations have moved from `Core` to `Driver`
5. TypeScript compiles the JS output from `@appium/types` (which is just a static "constraints" object)
Resolves#17518
- `@appium/test-support` now exports the e2e setup for plugins, and e2e/unit suites for drivers from base-driver. it also generates declarations.
- `appium` exports this as `appium/test`.
- The `capability.spec.js` unit test for basedriver now avoids spying on the "global" logger, due to test flake. It now spies directly on the function which calls the global logger. (@mykola_mokhnach)
- removed homebrew ansi-stripping code from `test-support` and replaced with `@colors/colors`
- type fixes and refactors for `@appium/test-support`
- type fixes for `appium`
- simplify `lib/index.js` of `@appium/base-driver`
BREAKING CHANGES
Some plugin tests were calling code which called the `update()` method of `DeviceSettings`, but there's apparently no code that actually sets the `onUpdateSettings` listener anywhere (maybe drivers can opt-in to this behavior?), which was causing exceptions to get thrown.
The E2E tests expected this code to reject, but the plugin tests expected it to _not_ reject, so I'm not sure what's right.
- adds unit tests for `DeviceSettings`
_Note: after further investigation, I think this was throwing simply due to `base-plugin` using an old version of `appium-fake-driver` which used an old `appium-base-driver`. @jlipps says this change is OK._
This was not as easy as the other two. The main issue involves the `BaseDriver` class and is threefold:
1. `BaseDriver` and a valid external subclass thereof (a `Driver`) are not the same, because the former is essentially _abstract_. There is no notion of an abstract class in JS nor in TS for JS.
2. Splitting `BaseDriver` into several modules and "mixing in" some modules is just not well-understood by TS.
3. `AppiumDriver` inherits _most_ of `BaseDriver`, but overrides some functions with differing signatures. This is unsupported by TS.
To work around these problems, I had to:
1. Move the `Driver` interface into `@appium/types`, since other packages may depend on it. We do not want circular dependencies, which is likely to occur otherwise. Further, there is no way to tell TS for JS that a class _implements_ an interface or type.
2. Refactor the mixins (in `basedriver/commands/`) into "mixin classes", as understood by typescript. These are dynamic classes returned by functions which accept a class parameter, and _extend_ that class. The result is marginally better, but the implementation is ... well, see for yourself. It is not possible to use declaration merging to just "trick" TS into thinking that `BaseDriver` has all of these extra methods; classes cannot be merged, and even if you could, you can't use declaration merging to "add" methods afaict.
3. `BaseDriver` is now an empty class which inherits from all mixins applied to `DriverCore`. Due to syntactic restrictions, it must be a `class` statement in order to use the `@implements` tag, which causes TS to check that the result fully implements `Driver`. `AppiumDriver` _also_ inherits from `DriverCore`, since it does not override `BaseDriver` "properly". `BaseDriverCore` itself is pretty small, containing only those functions which `AppiumDriver` defines as differing.
Otherwise:
- `BaseDriver` does not inherit from `Protocol`, which is just an empty class. `Protocol` was removed.
- All of the error classes are exported from `protocol/errors`, because TS cannot see them otherwise.
- Exported missing `GET_STATUS_COMMAND` from `protocol/index`
- Re-exported `normalizeBasePath` from `server` instead of `protocol`, since that's where it's defined
- Removed `index.d.ts`
- Mixins use `@implements` as well. Note that `@implements` does not support `import('..')` syntax.
chore(base-driver): attempted to make types for mixins less awful
fixed a couple issues in the types in `driver.js`
core(base-driver): add capabilities types
- also move the bluebird config into the index
- fix references to `DriverOpts`
- add `assignServer()` to `BaseDriverCore`, used by `AppiumDriver`
chore(base-driver): fix more types
add missing reference to `@appium/types` in `tsconfig.json`
fix(base-driver): ensure getLogEvents is async
fix(base-driver): add some more type checks and fix logCustomEvent to be async
chore(base-driver): reformat
This PR removes Gulp from `@appium/base-driver` and reorganizes the test files.
The build needs to be a little different since other modules depend on its `build/test/basedriver` module. IMO this should probably get moved elsewhere, but this does not break compatibility.
simplified some stuff that was giving me problems.
instead of doing a try..await..catch and calling `fail()` if the catch block wasn't called, just use `sinon-chai`'s `.should.eventually.be.rejectedWith(ErrorClass, /message/)`
depending on the order in which this test file is run versus others, it's possible that some will fail because of global logging weirdness. but normally this doesn't happen... keep an eye on it!
* chore: ban direct usage of sinon
Calling `sinon.stub()`, `sinon.mock()` etc., directly is error-prone. Care must be taken to explicitly restore any stub created.
Using a sandbox (via `sinon.createSandbox()`), you don't need to remember to restore everything you fiddled with.
To that end, I've converted all direct `sinon` calls into sandbox calls and **BANNED** direct usage of `sinon` via ESLint.
# Conflicts:
# .eslintrc
* test(base-driver): replace restricted sinon.spy() usage in server-specs.js
* test(support): formatting
Mykola Mokhnach