- `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
A thing we know about the `opts` object passed in to a driver constructor is that it does _not_ contain caps. This value is retained in `this.initialOpts`. Upon session creation, it _does_ contain caps.
This adds a new type, `InitialOpts`, which is the first parameter to a driver. In the future, it may accept a type argument, as currently any extension-specific options (defined via schema in `package.json`) are not typed.
Because `DriverOpts` is a superset of `InitialOpts`, this should not be a breaking change.
The mixin approach prevented subclasses of BaseDriver from narrowing the type of `this.settings`. Now, that's possible.
Also:
- removed an unused type argument from BD constructor
- and did some typedef aliasing
- remove unneeded type assertion from log mixin
- because BaseDriver implements `findElOrEls` (technically), any subclasses must not inherit an interface containing a non-identical `findElOrEls` -- not even narrowing. so to avoid this, we will need to make it as broad as possible; no more generic `Ctx`
- likewise with `getLog`
- fix return type of `setGeoLocation`
- fix return type of `getPerformanceData`
- fix return type of `removeApp`
- fix return type of `hideKeyboard`
- fix return type of `getSystemBars`
- fix signature of various `touch*` methods
- fix return type of `setNetworkConnection`
alternatively, the deprecated methods mentioned here should be removed.
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.
Another handful of fixes.
- remove second "extra" parameter from `Capabilities`, `NSCapabilities` `W3CCapabilities`. we were not using it anywhere to my knowledge. it was an escape hatch anyway.
- never assign `BaseDriverCapConstraints` as the default constraints, because this is confusing as hell. instead, drivers should use the `*DriverCaps` types which automatically pulls the base constraints in. applied across several workspaces
- renamed `DeviceSettings` => `IDeviceSettings` because `DeviceSettings` is a class.
- the session ID param of `Core`'s `sessionExists()` is actually optional (per the implementation)
- allow some modicum of type narrowing at the class level around settings and values returned by `ISessionHandler`'s methods. also, not all values in the raw settings object are of the same type `T`, so fix that
- `server`, `serverHost`, `serverPort` and `serverPath` are not members of `Core` (using `AppiumDriver` as a litmus test--it interacts with `Driver` types but does not have these properties itself)
- changed a few types to interfaces where possible
- moved a lost comment
- further dumbed-down the logdef stuff
- `Driver.driverData` is _always_ defined, since `Core` makes it an empty array.
- `DriverOpts` no longer contains "partial" caps; this it not quite right as the caps are not assigned until a session is created, but there's a conflict between some props which are _both_ server args and defined in constraints. anyway, this is what `initialOpts` is for
- fix some type disagreements in basedriver's "capabilities" module
The first arg of `PluginCommand` is a `NextPluginCallback` which now returns `Promise<unknown>` instead of `Promise<void>`, which was incorrect.
We use `unknown` rather than `any` because it forces us to be explicit about the return value of `await next()` if we are to call it.
Added a type `DriverCommandToPluginCommand` which essentially converts a `DriverCommand` to a `PluginCommand`. It's probably best used as a type guard or decorator, but it can "fill in the blanks" when overloading commands in a plugin.
Also normalized some of the `TArgs`/`TReturn` stuff.
- `PostProcessOptions` moved into `@appium/types`
- `shutdownUnexpectedly` cannot be marked `@protected` as anything used this way is inaccessible in mixins
- suppress a `@typescript-eslint` warning. this probably needs to happen in a few other files
These types were "wrong" in that it is exceedingly difficult to successfully implement `getLog()`, `getLogTypes()`, `supportLogTypes`, etc., in a third-party driver because you'd need to implement _all of it_ or _none of it_. It's especially bad because it does this without prescribing where the logs should be stored (which is by design). Oops.
This also moves some generics in the "find" mixins. This may change again later, but it's unclear that any given driver must declare what a "context" is, and that there can only be one per driver.
Mykola Mokhnach