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.
- update flattened schema fixture to match actual schema
- plugin/driver e2e tests were also busted
NOTE: test that checks for a symlink when doing a local install is _not_ passing in CI and I cannot reproduce locally. I have disabled the test for now.
`jsdoc` does not seem to be actually used anywhere. The only export from `@appium/docutils` I see actually used is `Mike` within the `build-docs` script in `appium/docs`.
referenced by the `jsdoc` config, these have also been removed:
- `docdash`,
- `jsdoc-plugin-typescript`
This PR groups all `@appium/*` packages together, but also:
- Replaces a handrolled config with some official presets
- Updates `README.md` with the correct usage and accurate information
* docs: fix .NET repo name in link
* docs: Rename repo in README.MD
* docs: Rename repo in ja/appium-clients.md
* docs: Rename repo in appium/README.MD
Kazuaki Matsuo