Due to the way which drivers currently include `@appium/base-driver`, it's possible for a driver to become out-of-date with respect to `AppiumDriver` and fail to implement the expected interface. This change partially reverts the addition of `Driver.assignServer()`, which is a new function that old versions of `@appium/base-driver` do not implement.
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`
- because we had not previously (before `base-plugin`) tried to consume the appium declarations ourselves, I found a problem where the reference to internal types (`types/`) was not referenced correctly. this was fixed by renaming the files to `.ts` so the declarations are generated and put in `build/` along w/ `lib/`. this necessitated explictly exporting all types
- fixed a problem with `Args` not allowing an `undefined` `subcommand` prop
- added an `AppiumEnv` type
- simplify `tsconfig.json`
- `e2e-test` is now `test:e2e`
- removed `pre`/`post` lifecycle scripts because it's hard to parse what's happening
- in CI, e2e tests do _not_ run in parallel, no extra build occurs, no types are built, and no lint happens. (types/lint happens in a diff job, and there aren't enough cores available for parallel mode to make a difference)
- removed a bunch of scripts to test individual packages. you can just `cd packages/<pkgname> && npm t`
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._
yeah this is my bad. if we really need the history I can redo this.
no significant changes; just the usual stuff about builds and types.
bonus: I figured out how to get webdriverio types working
Since plugin tests now depend on appium types, I discovered some issues...
- `PartialArgs` renamed to `Args`. This can be basically any object, but contains some "reflection" to tell "server" args vs "extension" args
- Added a type guard to help with this
- Reorganized `init()` slightly
- Updated some type references elsewhere in the codebase
Note that `ParsedArgs` (no generic) contains "server args", `ParsedArgs<T>` contains "either server or extension args", and `ParsedArgs<{subcommand: 'driver'|'plugin'>` contains "extension" args. In particular, no defaults or config settings get applied to "extension" args.
Also fixed wrong `types` path in `package.json`
previously, `close` was considered an overload, meaning that _both_ the original `close` (from `net.Server`) _and_ our async version were defined.
This was incorrect, since we fully monkeypatch `close`, so this change removes the original `close` declaration entirely
Moved the stuff in `test/setup-babel` into `test/setup` and then removed some cruft in the `test:*` scripts of each package referencing `test/setup-babel`
Jonathan Lipps