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.
Because it’s now under VCS, we shouldn’t remove it when cleaning, since that will probably result in a dirty working copy.
changed the `reinstall` script to call `npm ci`, which a) expects `package-lock.json` to exist, and b) removes `node_modules` before it installs stuff.
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.
This PR changes a few things:
- Extension problems are now displayed correctly at `appium server` startup. This was done by changing the default `npmlog` level, then reesetting it to `silent` when `winston` takes over (in `logsink.init()`)
- Extension problems are also displayed at install time.
- Improved performance of `appium <driver|plugin> install` in many cases by actually checking if the thing is installed _before_ installing it.
- `ExtensionCommand` uses a new console logging mechanism (`console` in `@appium/support`) tailored to CLI usage, since it is intended to be run via the CLI. Using this, we handle the result of extension checks both at server runtime and during CLI tool usage in the appropriate manner. The implementation is just a dumb wrapper around `console.log` and should eventually be removed when we revisit the logging architecture.
- Separated extension checks further into "errors" ("Problems") and "warnings". As these demand distinct log levels, `ExtensionConfig` no longer accepts a `logFn` in its constructor (since this restricted to a single level ("error"))
- Generally improved specificity, helpfulness, and reduced extraneous verbosity (like this sentence) of warnings
- Removed `strip-colors`, as this functionality is present in `@colors/colors`. The E2E test helper now automatically strips colors from child processes.
- More tests
- Change `e2e-helpers` to use `CliConsole` for command logging output during tests
- Change the "uninstall" command to use `npm uninstall`, since `rm -rf` will hose `node_modules` if the current project has a dependency on `appium` (in other words, if they are otherwise using a package manager to manage extensions). This is slower but safer.
renovate[bot]