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
- `@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
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.
- `@appium/test-support` now exports the e2e setup for plugins, and e2e/unit suites for drivers from base-driver. it also generates declarations.
- `appium` exports this as `appium/test`.
- The `capability.spec.js` unit test for basedriver now avoids spying on the "global" logger, due to test flake. It now spies directly on the function which calls the global logger. (@mykola_mokhnach)
- removed homebrew ansi-stripping code from `test-support` and replaced with `@colors/colors`
- type fixes and refactors for `@appium/test-support`
- type fixes for `appium`
- simplify `lib/index.js` of `@appium/base-driver`
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.
This changes how plugins handle CLI args:
- The `cliArgs` instance prop of a `Plugin` will never be `undefined`. If there are no args, the prop will be an empty object.
- The `cliArgs` instance prop of a `Plugin` will now contain default values, if any were provided by the `Plugin`'s schema.
This differs from how the same property is handled in drivers. To that end, I split `AppiumDriver#getCliArgsForExtension()` (previously `assignCliArgsToExtension()`) into two separate methods for clarity.
This change also contains a few associated improvements to tests and types.
This PR changes the shape of plugin classes as well as how CLI args get assigned.
- The `pluginName` static property has been removed. `name` is now assigned via the `BasePlugin` constructor, and is derived from the plugin name in the manifest. This means that an implementor only needs to provide a `pluginName` in the manifest, and the data is not duplicated. The value in this map (the plugin name) is used to instantiate the plugin, instead of passing static `pluginName` property into the constructor.
- CLI args are now passed in through the constructor instead of assigned to the plugin instance after the fact.
Implementation details:
`getActivePlugins()` and `getActiveDrivers()` now return a `Map` of an extension _class_ to an extension name. The key is _not_ an instance, and is effectively a singleton, so we are not at risk of a memory leak.
This change does not otherwise affect drivers.
Resolves#16924
Because the `postinstall` script of `appium` needs functions in `@appium/support`, that module must be compiled _before_ its `postinstall` script runs. Prior to this PR, only the monorepo root would run a `postinstall` script to build the subpackages. Now, each package has a `prepare` script which runs its own build; this happens prior to any `postinstall`. This way, the `postinstall` script in `appium` can run successfully.
This change modifies the type of `BasePlugin.newMethodMap`, adds a
parameter to the `MethodMap` type, and updates the base plugin TS
config for better incremental builds.
This is a "fix" but only for the dev environment.
Further:
- add install of `mjpeg-consumer` to CI, since it may have disappeared from the environment
- remove `overrides` from `@appium/support`'s `package.json` since it no longer seems needed
Moved the stuff in `test/setup-babel` into `test/setup` and then removed some cruft in the `test:*` scripts of each package referencing `test/setup-babel`
- since `appium` is already required to start the server, might as well use it instead of `npx appium` to install drivers & plugins
- supports `appiumHome` option
- improved console output
- fix dev script to build helpers
- remove `test/helpers.js` from TS config (adding TS support to test files will be another PR)
Jonathan Lipps