This adds [commitlint](https://npm.im/@commitlint/cli) to the project which validates commit messages against the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec via a preset.
Removed the [pre-commit](https://npm.im/pre-commit) package as it has not been updated in six (6) years; replaced with [husky](https://typicode.github.io/husky/) which is widely-used and full-featured.
Customized commitlint so that it will allow commit messages lines of arbitrary length; this is set to 100 by default, but is not in the specification. If someone has a good reason that we _shouldn't_ disable that rule, please say something!
Closes#17844
response to PR review
- "ref" is not used as a suffix in any vars. if it's a reflection its usually ending in "refl", or if it's just data, it ends in "data"
- short-circuited deep loop(s)
- many more types and type guards to attempt to simplify the crawling of reflections for data
This is a typedoc plugin based on `typedoc-plugin-markdown`.
It outputs everything that plugin outputs _plus_ it outputs information about commands (API endpoints) as defined in drivers, plugins, and the builtins in `@appium/base-driver`
It's written in TS because that was the easiest way, because a) there was some sort of disagreement between Babel and TS re: exports, and b) everything it's built on is written in TS.
The current intended behavior (to use the "parent dir") as the scope is often or always broken. An empty scope within parens is actually an invalid conventional commit message. So instead of `chore():` it will be `chore:`.
We could instead pick a scope (like `deps` or something) but figured it was not important enough to do.
The schedule is helpful in the context of a larger monorepo like Appium, but not so much in the context of a standalone package which consumes the shared config.
* append the initial jp resource
* update a few
* comment out
* add for translations
* update the index
* add <br> to void unnecessary space by GitHub
* remove new line to void unnecessary space by GitHub
* tweak translations
* tweak
* add a few in intro/index.md
This adds a module `lib/extension/manifest-migrations` which contains functions that migrate `extension.yaml` files to new versions.
- constant `CONFIG_SCHEMA_REV` renamed to `CURRENT_SCHEMA_REV` and moved into `constants` module
- removes references to removed `PluginRecord` and `DriverRecord` types
- `ExtensionFields` is now `ExtInstallReceipt`
- renamed private fields in `Manifest`; see L365-385 for logic changes
- updated test code
This uses the new v3 version of the manifest schema to add an `installPath` property to every extension in `extensions.yaml`. This fixes an issue where extensions may not be able to be _instantiated_ within an extension dev environment.
This is a breaking change if someone is actually using the `npm` module out of `@appium/support`. Personally, I'm gonna go with "no"
The signature of `installPackage()` has changed from returning a parsed `package.json` to returning an `NpmInstallReceipt` object, which contains parsed `package.json` prop `pkg` and `string` prop `installPath`.
Because `@appium/base-driver` needs `BASE_DRIVER_CAP_CONSTRAINTS`, we need to build on `prepare`. But we cannot build on `prepare` if the file this var is in needs to be built via `tsc`, because the TS project is built as a whole. The `prepare` scripts of each package run _before_ the `prepare` script of the monorepo, so the file simply won't be available.
Anyway, that file is now a `.js` file and is compiled via `babel` like the other packages.
Also tweaked `reinstall`/`clean:packages` scripts
# Conflicts:
# packages/types/lib/index.ts
This PR modifies the `Args` type to understand extension subcommands (e.g., `driver install`).
Now the `Args` object that gets passed around will know if the args are for running the server or an extension command, and if the latter, which subcommand and what extra options that subcommand supports (e.g., `driver list --show-installed`)
Further, the `main()` export from `main.js` now uses a conditional type based on the command to know if it will resolve with an `AppiumServer` or `void`. Previously, this was just a union type; now it is smarter and easier to use.
Christopher Hiller