- Some types in `appium` were renamed
- Others avoid errors
- Some are minor tweaks to `tsconfig.json` files
# Conflicts:
# packages/appium/lib/extension/extension-config.js
# packages/appium/types/extension-manifest.ts
# packages/appium/types/extension.ts
# packages/base-driver/lib/jsonwp-proxy/proxy.js
# packages/support/lib/logging.js
# packages/support/test/unit/logger/logger-force.spec.js
Closes#16738
There's a difference between assigning things to a prototype and public class fields, evidently.
To test this would be best done via interaction between drivers and `base-driver`, but affected drivers do not necessarily run the reusable test suite. Fundamentally, a unit test for this would be testing Babel. Unsure of best way to add an E2E test
- Also fiddled with some types, which still aren't quite right, but better.
- Simplified a `_.reduce()` call
- these are first and foremost _server_ args, so go with that, except they _also_ get provided to drivers, so we can use the `DriverOpts` alias there.
- simplify `tsconfig.json` in `@appium/types`
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 now consumes Ajv directly to validate CLI args. Since a JSON schema is made of JSON schemas, we can simply validate an argument against _the schema for that argument_.
- Replaced parser transformation functions (`parseSecurityFeatures()`, `parseJsonStringOrFile()`) with custom transforms which are bound to keyword `appiumCliTransformer`. e.g., any option that can now accept a JSON string or filepath on the command line may use `appiumCliTransformer: 'json'`. This is the default behavior for `array` and `object` -type options, which cannot easily be expressed on the CLI. The config file does _not_ support this behavior, so the value must be whatever the schema `type` says (e.g., an `object` instead of a JSON string or filepath). To this end, removed `parser-helpers.js`
- Further, we now disallow union types in the schema. A prop must have a single type.
- Added custom keywords `appiumCliDest`, `appiumCliDescription`, and `appiumCliTransformer`. Previously (if existed), this could have been any value--these are now typed by the schema--e.g., a number for `appiumCliDest` will fail.
- Added more types and TS checks around
- Fixed misspelling of "successfully" in various places
- Removed `@oclifg/errors` because we can now use `better-ajv-errors` to display them, as intended. It looks great!
- Moved all schema-related stuff to `lib/schema/` because I had too many modules
- Added more constants to please @mykola-mokhnach 😄
- Handles untyped properties or `null`-typed properties
- `getSchema()`, `validate()` etc now accept a schema ID. The schema ID is derived from the argument name. This is how we handle validation for each argument individually. The config file is still validated against the entire schema at once.
- Fixed problem where only `driverConfigs` were ever used to call extension commands!
- Added some semaphore-like things to `ExtConfigIO` to avoid multiple reads/writes at once
- Fixed display of metavars in `--help`
- More tests; removed tests for removed code
Jonathan Lipps