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.
npm may have changed its behavior around installation of packages at local paths, but `npm install /path/to/thing` no longer seems to create a symlink.
the `installPackage()` method in `@appium/support`'s `npm` module now accepts an `installType` option. if the value is `local` an `npm link` will be performed; otherwise an `npm install` will be performed.
- (appium) reverted some changes I made to a test in `driver.e2e.spec.js`
- `installViaNpm` now wants an `installType` option. this is required
- removed a redundant script
These arose when attempting to generate docs
- Errors now all have optional params in constructors; normalized param name
- Validate `METHOD_MAP` against an actual `MethodMap`
- Set `cliArgs = {}` as default in `server()`
- Rename `SessionCommands` to `ISessionCommands`
- The "context" in `IFindCommands` is now a generic of any type
- Made various props in `ExternalDriver` optional; `ExternalDriver` now accepts generic `Constraints`
- `proxyCommand` accepts a generic return value
- Removed unnecessary second generic type param from `DriverClass`
This change:
1. Makes both `MethodMap` and `ExecuteMethodMap` considered "read only". This is not _entirely_ true, as there's a bit of code that munges `ExecuteMethodDef` objects, but it's good enough for usage.
2. They both now accept a generic `D`, which is by default `Driver`. Since a `Plugin` can also use `newMethodMap`, there's a conditional type here to add everything from `ExternalDriver` only if it's a `Driver`. This generic allows proper validation of the map itself (command names must exist!)
3. `Constraints` is now also considered `Readonly`, since it is, in practice.
4. `executeMethodMap` is now actually optional
5. Renamed `Method` to `MethodDef` for consistency
looks like some formatting happened too
Run `npm run typedoc` to generate docs in `typedoc-docs` dir.
I thought I'd take a few mins and set this up. It was _mostly_ straightforward, except:
1. Figuring out the "entry point" for each package was difficult until I realized `.js` entry points are assumed to be compiled, and thus require a `sourceMappingUrl` reference. IMO this is probably a bug in TypeDoc
2. The `sourceMappingUrl` must reference an external sourcemap file; not an inline source map. If it's an inline source map, the system tries to `fs.open` a large data-url.
3. The babel config does not control whether external sourcemaps are created; `@babel/cli` does. So I needed to change those.
4. Practically speaking, I don't see any drawback to external sourcemaps _yet_
5. TypeDoc has poor support for cross-package type references in monorepos, and I had to add a plugin which implements a workaround
6. Per some suggestions in the docs, I modified the order of references in the root `tsconfig.json` to start with "the biggest one first"
I didn't modify any types or docstrings anywhere.
Christopher Hiller