This change modifies the type of `BasePlugin.newMethodMap`, adds a
parameter to the `MethodMap` type, and updates the base plugin TS
config for better incremental builds.
The peer dependency value is stored in the `extensions.yaml` manifest for each extension as `appiumVersion` (if present).
If the peer dependency is _not_ present, the user will be warned, but Appium will still try to load the extension (I have a feeling that most of the time, this will be fine). When warned, the user will receive information about available extension upgrades, if any.
This required some refactors in the `lib/extension/` dir. Extension validation was previously a synchronous process, but because we now (potentially) display information to the user about upgrades (which is async), validation must also be async. This means that the `ExtensionConfig` constructor (and the constructors of its subclasses) cannot run validation. Validation must happen after the config object is instantiated, which is handled in `loadExtensions()` of `lib/extension/index.js`. The constructor signatures have changed accordingly.
While extensions now soft-require a `peerDependencies.appium` field, in the monorepo, the value of this dependency is `file:../appium`. This is treated as a special case, and acts as if the dependency is just the current version of `appium` (as in its `package.json`). This is handled in `Manifest#addExtension()`.
To further support this, `appium` now exports `@appium/base-driver` as `driver`, `@appium/base-plugin` as `plugin`, and `@appium/support` as `support`. `tsconfig.json` files have changed in these affected packages.
In addition, a new reusable TS config file has been added for use with basic plugins.
# Conflicts:
# .eslintrc
# packages/appium/lib/extension/extension-config.js
# packages/appium/lib/extension/index.js
# packages/appium/lib/extension/manifest.js
# packages/appium/test/unit/extension/manifest.spec.js
# packages/appium/test/unit/extension/mocks.js
This changes the TS configuration to to a) emit declarations for supported packages, and b) build declarations incrementally by package.
To begin, we are targeting `appium`, `@appium/base-driver` and `@appium/support` for declarations; these three are intended to be published with declarations generated via their JS.
Both `@appium/support` and `appium` are fully typechecked (sans implicit `any` types), but `@appium/base-driver` is mostly not. Regardless, declarations are generated for all three.
Each package will have its own `tsconfig.json` which "inherits" from `config/tsconfig.base.json`. Each will also need to declare relative paths to dependencies. e.g., the `appium` package must configure its `tsconfig.json` so that it depends on the declarations of `@appium/support` and also where to find `@appium/support`. Essentially, a small dependency tree gets built, and those at the "root" get their declarations built first; then the consumers use those declarations.
Also reorganized some scripts and added `npm-run-all` to help and added a "typecheck" job to CI.
Since `npm install` will build, it's pretty inconvenient to have `npm` abort installation if the build fails. In that case, if any of the build steps fail (see `build:loose`) the installation will continue. Added a `prepublishOnly` which runs a build in "strict" mode where everything must pass.
_Note: there's still a strong coupling of "what `BaseDriver` provides" and "what an external driver *may* provide". It's unclear to me if this is a problem, though there seem to be a handful of methods that external drivers *must* implement. The easiest way to get around this would probably be to extract these required properties and methods into their own interface (duplication) if we cannot otherwise declare methods as "abstract". As it stands, the `Driver` is basically just `BaseDriver`._
Also:
- Moved some configuration types out of `appium` and into here, since they are used both by `appium` and `base-driver` via `DriverOpts`
- Split `Driver` type into "the thing that BaseDriver is" and "all the other methods external drivers can implement"
- Added missing `proxyCommand` method
- Better generics for `LogType`
- Remove unused `Constructor` type
- Better types for `getSession`/`getSessions`
- Added util `Class` type
- Added many missing typings from DefinitelyTyped
- Added `ts-node` for `@wdio/types` (I need to send a PR to webdriver to eliminate this dependency)
- Type checks in their CI step
Christopher Hiller