The resulting solution keeps a bunch of weak refs to `Consola` objects and sets the log level on all of them if it ever changes.
This is--at minimum--easier to understand than the broken `Proxy` implementation.
This makes `ls` an alias of `list`; e.g., `appium driver ls`
While doing this I noticed a limitation of `argparser`, which is that an option (not a command) can only have a single (1) alias. I have noted this behavior in a comment.
I also notice that we need to rewrite `ls` to be `list` ourselves, or we will have a bunch of conditionals checking for both values scattered around.
We need to use yargs...
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.
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
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.
mainly because a "command" is a thing in drivers/plugins, and these classes refer to something else completely unrelated. renamed to `*CliCommand` to avoid confusion.
This removes `longjohn` and replaces it with a statement which increases the stack trace limit from the default (10) to 100.
I believe setting this overrides whatever was passed to the runtime `--stack-trace-limit` option. If someone complains, we can try a different strategy.
Closes#18357
Christopher Hiller