In the case of `appium-xcuitest-driver`, each command (or execute) method is declared like so:
```ts
import {someMixin} from './some-mixins';
class XCUITestDriver {
foo = someMixin.foo;
}
```
The docstring exists on `someMixin.foo`, but not on the `foo` prop of an `XCUITestDriver` instance.
This change makes `@appium/typedoc-plugin-appium` dig into such references and derive the comments.
This causes the "Build" workflow to only trigger if the PR modifies files in paths that might affect the build.
Likewise, the "Build Docs" workflow is expanded to rebuild docs if API changes occur (e.g. in sources).
Also restricts perms a bit more on docs build.
`lerna publish` has been acting up, and I think it's because the lifecycle scripts don't do enough cleanup, or we're running them in the wrong order, or something. so here's this.
it causes an "extra" rebuild between version and publish, but I think it's better to be safe than sorry here.
These can now return `T` and `T[]`, respectively. `T` defaults to `string`, but in `appium-xcuitest-driver`, `T` is either `string` or an object, depending on the settings.
- Doc gen for:
- `@appium/driver-test-support`
- `@appium/opencv`
- `@appium/plugin-test-support`
- `@appium/test-support`
- Added a `dev:docs` script in the root monorepo. The file watcher does _not_ presently rebuild reference docs upon changes to sources (which is a limitation of `@appium/docutils`).
- Changed the `dev:docs:*` scripts in `appium` to use `appium-docs` (so it rebuilds reference docs at least once [because it runs typedoc!!])
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
Christopher Hiller