- `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
This change removes types for methods in `ExternalDriver` (or rather the interfaces that build it) that were marked `@deprecated` and consumed by `appium-xcuitest-driver`. I salvaged what I could from the descriptions in these docstrings, and have moved them into `appium-xcuitest-driver` (obviously not in this repo).
Also:
- created some new files to group types logically
- created a `HTTPHeaders` type
- created a type `ConfigureAppOptions` for `DriverHelpers.configureApp`, and a `PostProcessOptions` type within it.
- added a couple other types
- fixed some signatures to look more like reality
- modified the return value of `queryAppState()` to return `0|1|2|3|4` instead of `0|1|3|4` since `appium-xcuitest-driver` returns the former
- made the `LogDef` and related types even _more_ loose. tbh these are very awkward to type properly; I cannot figure out a good way to narrowly type the `self` param to a log `getter`.
- noted which of the remaining `@deprecated` methods in `ExternalDriver` were _not_ in use by `appium-xcuitest-driver`, so I can later remove them once I've salvaged the docstrings to put into `appium-uiautomator2-driver`.
This PR does a handful of things:
1. It adds a `--verbose` flag to `appium <driver|plugin> list` which just dumps a big object (via Node's `util.inspect()`), which contains the underlying manifest file data
2. It creates a new manifest schema revision where the "install type" can be `dev`. Added a migration.
3. Displays a warning if trying to uninstall an extension in dev mode
4. Displays `[installed (dev mode)]` instead of `[installed (npm)]` when running `appium <driver|plugin> list` w/o `--verbose` flag
5. Attempted to simplify the return type of `ExtensionCommand.list()`
Closes#18277
In certain situations in `.ts` sources, class definition lines can get very long. Prettier will split these into multiple lines, and add a final line with `{` at position 0. This conflicts with the `brace-style` rule in ESLint. I am not sure why the ESLint prettier config doesn't already handle this, but I am going to guess it's because that config doesn't work on `.ts` sources.
BREAKING CHANGE: This makes `@appium/eslint-config-appium-ts` also apply to JS sources _and_ requires a new peer dependency (`eslint-import-resolver-typescript`). The `main` file is now a `.js` file. The module is expected to _extend_ `@appium/eslint-config-appium`, not replace it; consumers needn't extend both in their ESLint config.
In the not-too-distant past, `@typescript-eslint/parser` was unable to understand docstrings in `.js` files. Evidently this is no longer true.
I've rewritten and heavily commented the configuration explaining the intent behind everything.
This change ensures when running `mkdocs` or `mike` with the `--serve` flag, the output is unbuffered and stdio is inherited from the parent process.
This will show helpful things like _the URL at which the development server is running_.
Currently there is no way to specify a log level when running extension commands (e.g., `appium driver list`). Further, the log level used by the support module depends on whether or not Appium set it; used outside of an Appium context, there is no way to programmatically set the log level of the support module via an external API.
To that end, I just removed the log messages, because a "proper" fix will be quite involved. See #16970.
This change makes it so when running an extension script (e.g., `appium driver foo run some-script`), unless the `--json` flag is present, the child process will do no buffering whatsoever and will inherit `process.stdin`, `process.stdout` and `process.stderr` from Appium.
This means that extension scripts can do stuff like prompt the user for input. It _also_ means they can do stuff like display progress bars and spinners.
If the user wants JSON data, we revert to the old behavior, which is to buffer the output and dump it once the script has completed.
Christopher Hiller