This makes a small handful of fixes related to type consumption:
- `@appium/types` is now a direct dep of `appium`. Without this, types leveraging `@appium/types`--e.g., `BaseDriver`, which is based on a `Driver` interface defined in `@appium/types`--fail to be understood fully by a consumer (such as an extension). Extension authors would need to install `@appium/types` as their own dev dependency. This change makes addition of `@appium/types` unneeded when consuming types exposed by `appium`, `appium/driver`, `appium/support`, etc.
- At this time, consumers will still need to add `@appium/types` if they wish to directly reference types defined in here (such as `W3CCapabilities`).
- In manual testing of the exported types, I found two issues in `appium/lib/schema/arg-spec.js` and `appium/lib/schema/schema.js` which were relative type imports and only worked in the context of the monorepo. I fixed these.
- `@appium/types` previously re-exported types defined within `axios` (`HTTPMethod`); I just copied and pasted what we needed to avoid the production dependency on `axios`.
- `@types/express`, `@types/npmlog`, `type-fest` and `@wdio/types` were added as production deps to `@appium/types`, as these are needed. However, these are packages _only_ containing types, unlike `axios`. There's a lesson to be learned here, but I don't know what it is.
* #16817 2.0 Chinese mkdocs-zh.yml
Rebase the code for mkdocs-zh
* #16817 2.0 Chinese mkdocs-zh.yml
Change the folder from cn to zh as mkdocs required
* #16817 2.0 Chinese mkdocs-zh.yml
Change the relative link from en to zh
* #16817 2.0 Chinese mkdocs-zh.yml
Translate some titles to trigger the build
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.
Christopher Hiller