- `@appium/test-support` now exports the e2e setup for plugins, and e2e/unit suites for drivers from base-driver. it also generates declarations.
- `appium` exports this as `appium/test`.
- The `capability.spec.js` unit test for basedriver now avoids spying on the "global" logger, due to test flake. It now spies directly on the function which calls the global logger. (@mykola_mokhnach)
- removed homebrew ansi-stripping code from `test-support` and replaced with `@colors/colors`
- type fixes and refactors for `@appium/test-support`
- type fixes for `appium`
- simplify `lib/index.js` of `@appium/base-driver`
When any package here is consumed as a library, the production deps installed alongside it _must_ also include depenencies related to type information. If these packages _aren't_ included, consumers will not have the requisite declarations installed and will get incomplete type information--at best--or worse; compilation errors.
Putting the onus on the consumer to install these requisite types is both user-hostile _and_ can result in the incorrect versions of type declarations being installed.
To that end, I've moved the various type declaration deps to production deps of the packages in which they are used. Sometimes this is multiple packages (in the case of, say, `@types/teen_process`). This results in many types being removed from the monorepo root. Those that remain are for _dev dependencies only_. If a packages uses, say, `ws`, but only in its tests, then the types can remain in the monorepo root along with the rest of the common dev deps.
I also saw an unused `supports-color` in `appium` and removed it.
This uses the [boneskull/nodejs-production-test-action](https://github.com/boneskull/nodejs-production-test-action) GH action to run a smoke test across all packages.
The action does the following:
1. Runs `npm pack` on each package, writing the tarball to a temp dir. This tarball contains the package as a user would `npm install` it.
2. Changes into the temp dir and runs `npm install <tarball>` on each
3. Runs a specified script (in our case, `test:smoke`) in each installed package's dir in `<tmp_dir>/node_modules`
Because `devDependencies` will not be present, this should avoid a class of issues where production deps are miscategorized as dev deps.
The action should probably use a separate temp dir for each--in the case of a dependency being present but only because some other package depends on it--but it's not smart enough to figure out peer dependencies yet.
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.
- 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
* 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>
This is a "fix" but only for the dev environment.
Further:
- add install of `mjpeg-consumer` to CI, since it may have disappeared from the environment
- remove `overrides` from `@appium/support`'s `package.json` since it no longer seems needed
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`
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._
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`
Christopher Hiller