This is getting pretty close, but:
- Commands from a driver will show even w/o a `newMethodMap` or `execMethodMap`; it is able to understand that it's overriding `BaseDriver`
- It's also able to understand the associated routes
- And it's able to understand the routes even if `BaseDriver` does not implement it
Still working on the parameters display, but we have the name override working at least.
Added some docstrings in `fake-driver`, `base-driver` for testing
This change makes Lerna execute E2E tests across two cores. Some of the slower E2E suites (`appium`, `support`, `opencv` and `base-driver`) also run in parallel via Mocha's `--parallel` flag.
In Appium, the main culprit was `cli.e2e.spec.js`, which I split into four files: `args` (argument handling), `cli-driver` (`driver` command), `cli-plugin` (`plugin` command) and `local` (behavior when Appium is a dependency). This should run faster (in theory) since Mocha runs tests in parallel _per file_ and will expand to the available cores.
CI has limited cores, so this won't really help there--but it will speed up local development. When running tests locally, you may see various delays, as Mocha buffers the output of a single test file.
This is a continuation of the work I did in #17252.
This pulls in some recommended settings from `@tsconfig/node14` (a proper TS target configuration for Node.js v14; ours wasn't _wrong_ per se, but this is better) and allows us more flexible use of `ts-node`. Use of this module is recommended by `ts-node` (which we need to run tests).
`ts-node`'s behavior changes _depending on the directory in which it's run_--and this can cause some really nonsensical bugs--so the changes here ensure that it will act the same regardless of if you're running tests from a package directory or the monorepo root.
Also:
- Ensure various `clean` scripts don't fail if they've been run before `build`
- Enable `strict` mode in `@appium/types` cause we can
- Fix a type issue found in `@appium/support`; this does not appear to have been a traditional bug but rather a type disagreement surfaced by the new config
# Conflicts:
# package-lock.json
# packages/typedoc-plugin-appium/tsconfig.json
- `@appium/gulp-plugins` does not use `tsc` and continues to use...whatever it uses.
- `@appium/doctor` now has generated declarations, though I didn't bother to do anything with the types
- rewrote swaths of build scripts:
- removed the `fix` and `lint` scripts from each workspace (package) since I don't think they get used and they are of limited value
- for tests and autoinstallation of extensions, added `ts-node` for on-the-fly compilation
- workspaces _can_ define their own `build` and `clean` scripts (both should be required if either is used). these do not currently get run when running `npm run dev`, but they do occur on a bare `npm install` from the monorepo root or a `npm run reinstall`.
- `npm run rebuild` does a fresh rebuild, but does not clean any `node_modules` dirs nor does it reinstall anything.
- removed `prepublishOnly` since `preversion` does the same thing
- `npm test` now runs `build`/`lint` in parallel
- postinstall script of `appium` ("autoinstall") script now must call `npm run build` if in a fresh dev environment. this is because a) lifecycle scripts of packages run before lifecycle scripts in the monorepo root, and b) `postinstall` runs before `prepare`. so there's really no way around it; even using `ts-node` fails because other modules depend on `@appium/support/index.js` which expects the pkg to be built.
Closes#17746Closes#17807
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`.
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
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.
server option `log-filters` is now supported via embedding in Appium config files _or_ via CLI using an external JSON file.
example fixtures included.
Note that the `Rule` type has been replaced with the `LogFilter` type automatically generated from the schema (see previous commit).
Jimp will not get upgraded so we need to do this to avoid the vuln in older versions of jpeg-js.
I also removed the relative deps from the monorepo root since they seemed to befoul the overrides. They are no longer needed due to workspaces (I think)
This change makes Appium recognize the existence of an extension in the current (or parent) dir, and automatically adds it to the extension manifest.
Resolution of Appium (e.g., _how_ Appium was installed) is no longer taken into account when determining if we're "in" a package that depends upon Appium. So you can easily `npm link appium` in an extension working copy if you wish, and this will not impact Appium's behavior.
To support this change, `hasAppiumDependency()` in `@appium/support`'s `env` has changed to be a wrapper around the new `findAppiumDependency()`. The strategy here is to use `npm list --long` to get detailed information about the current directory. The result will have an object with a `path` property, and that property points to the current workspace root (or current project root). We can then read the `package.json` in the `path` property--or just the CWD--to make the determination about an `appium` dependency (or lack thereof). For extension working copies, this will return `true` because `appium` will be present in `devDependencies`, `peerDependencies`, or both. For any other project, it will usually just be in `devDependencies`. If there's no `package.json` in the CWD and we're not in a workspace, Appium continues to use the default `APPIUM_HOME`.
One side effect of this is that running `appium` from the monorepo itself treats the dir hierarchy as a package which has an `appium` dependency (because it does!). To that end, the default `APPIUM_HOME` will _not_ be used when running `appium` from _anywhere in the monorepo_ unless you explicitly set `APPIUM_HOME` in an environment variable. Generally, our tests prescribe their own temporary `APPIUM_HOME` directories, so this should have no effect on them (in the general case). It _will_ have an effect on running `appium` manually in a development environment, as the workspace root will be treated as `APPIUM_HOME`; running `node ./packages/appium/index.js driver install uiautomator2` (or `npm start -- driver install uiautomator2`) will install that driver as a dev dependency (and save it). I could add a special case _just for the monorepo_ if we don't want this to happen, but it may introduce complexity we/I don't want to maintain, so I left it out. Furthermore, `npm start -- driver list` will show the `fake` driver, and `npm start -- plugin list` will show all of the plugins in `packages/`.
Regardless, I view this as a solid win for extension developers.
Bonus:
While I don't have benchmarks, this should considerably improve performance when detecting locally-installed (`node_modules/some-extension`) or extension working copies. Instead of using `klaw` to walk the filesystem (in serial!) we can just use `glob` to look for relevant `package.json` files. Instead of waiting until `glob` is completely finished searching, we can listen for its `match` evens and begin processing `package.json` files as soon as they are found. Because `@appium/support` only exposes a promisifed `glob()`--with no access to the `EventEmitter` it returns--`appium` depends on `glob` directly.
This is handy for drivers which need to find executables in the filesystem.
Also fixes possible false-positives in `fs.exists()`/`fs.hasAccess()` on Windows.
Jonathan Lipps