Resolves#16924
Because the `postinstall` script of `appium` needs functions in `@appium/support`, that module must be compiled _before_ its `postinstall` script runs. Prior to this PR, only the monorepo root would run a `postinstall` script to build the subpackages. Now, each package has a `prepare` script which runs its own build; this happens prior to any `postinstall`. This way, the `postinstall` script in `appium` can run successfully.
These two deps are devDependencies of the monorepo root. Since we do not use TS in any "production" capacity, typings should not be production dependencies anyway.
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.
- Some types in `appium` were renamed
- Others avoid errors
- Some are minor tweaks to `tsconfig.json` files
# Conflicts:
# packages/appium/lib/extension/extension-config.js
# packages/appium/types/extension-manifest.ts
# packages/appium/types/extension.ts
# packages/base-driver/lib/jsonwp-proxy/proxy.js
# packages/support/lib/logging.js
# packages/support/test/unit/logger/logger-force.spec.js
- Also split out types into more files, since they were getting hefty
- The `Plugin` type conflicts with the [Plugin API](https://developer.mozilla.org/en-US/docs/Web/API/Plugin), which is detailed in TypeScript's DOM library. This changes makes `@appium/types` _avoid_ this library entirely, and only use the basic JS/Node.js types.
# Conflicts:
# packages/appium/types/extension.ts
# packages/types/lib/index.ts
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
* chore(images-plugin): update dependency lru-cache to v7.9.0
* Update cache properties
* Only set max size
* Set max cache size
Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: Mykola Mokhnach <mokhnach@gmail.com>
`import` in jsdoc types previously using relative paths to reference the `types` folder can now be referenced via `appium/types`; e.g., `import('../types').Foo`, `import('./types').Foo`, `import('../../../types/bar').Foo` are now just `import('appium/types').Foo`
Also add some missing descriptions
BREAKING CHANGE:
`@appium/eslint-config-appium` now requires peer dependency `eslint-config-prettier`. Because `@appium/gulp-plugins` always uses the latest development version of `@appium/eslint-config-appium`, the dependency needs to be added there, too.
In addition, this disables some rules, so _may_ cause code which previously passed lint checks _not_ to pass lint checks.
This reverts commits b34b75a80e, 88a6655253 and d89203f96c which, as a whole, was breaking.
This will fix the publish of v5.1.0, which should have been a major release.
After v5.1.1 has been released, this PR should be reverted in prep for v6.
these rules also conflict with prettier. prettier does something very similar, but not exactly. w/o this, running `prettier` then `eslint` will cause an eslint error.
Renovate Bot