- `env` module exposes functions for determining `APPIUM_HOME`, where various files should live, etc., by examining the runtime environment
- fixed some functions in `fs` which unnecessarily used `this` (which prevented dereferencing)
- added `walk()` to `fs` which just exposes `klaw` (since `walkDir` has very limited behavior). this enables `walk()` to be used as an async iterator, which is handy.
- fixed a bunch of types in the `util` module. involved some actual code changes, but the original code only worked by chance.
- removed `strict` option from `util.coerceVersion()`, since the option isn't actually used anywhere. this should be considered a breaking change if some module somewhere _else_ uses it and we consider it a public API. I'm pretty sure that's not the case, so.
- Upgrade TS to `next` tag. It's "safe" to use using bleeding-edge TS here since we don't actually use it to compile anything
- Add a bunch of missing types: `find-root`, `klaw`, `lockfile`, `mv`, `ncp`, `rimraf`
`--show-config` was not able to distinguish between defaults and values provided on the CLI. now it does. `--show-config` now displays (in this order):
1. any settings from the defaults (across Appium and any extensions)
2. any settings specified in config files
3. any settings specified on the CLI
4. the final merged configuration
Ref: #16340
* feat(appium): rename --show-config to --show-build-info
* feat(appium): add --show-config
This adds a new CLI flag: `--show-config`. When called, this will dump the values of a) arguments to the `init()` function of `main.js` _or_ args passed thru CLI, b) any config pulled from a config file, and c) the defaults as defined in schemas.
Each section is separated, and `undefined` values are omitted.
Instead of a JSON blob, the output just uses `console.dir()`.
To make this work, some refactors were needed:
- Use of `store_true` "action" for `argparse` in are now `store_const` with `const: true` because `store_true` sets the value to `false` if the flag is not present. This essentially assigns the default value of the flag (`false`) before it should; default values must come from the schemas.
- Along those lines, removed default values from the "extra" boolean args in `args.js`
- The CLI parser now ignores `undefined` values of arguments
Other:
- Created some types for extension classes and added the `server` prop to `AppiumDriver`.
- Enabled TS checks on `lib/config.js` (where `showConfig()` lives) and `test/config-specs.js`
- Removed unnecessary call to `validate()` in `preflightChecks()`; CLI arguments are validated individually (defined in `lib/schema/cli-args.js`) and the config file is validated separately (defined in `lib/config-file.js`).
- Add more types to `main.js`; rewrite `getServerUpdaters` in lodashese for fun (which I am happy to revert)
- Fix missing type aliases in `test/cli/cli-helpers.js`
- Misc types/refactors in `config-specs.js`
- Update parser tests to reflect that `undefined` values and empty objects are eliminated from the parsed arguments
Notes:
- The `showBuildInfo()` test in `config-specs.js` (which is ostensibly a unit test) forks `git` and also seems to require network connectivity, at least on my box. This stuff should be stubbed out or moved into an E2E test.
Resolves#15672
* chore(appium): remove unused options in `toParserArgs()`
This PR moves the FOSSA check from the Node workflow to its own. It won't run if the API key secret is not present (which would be true when running PRs from forks).
In addition, the check
1. will only run on changes to any `package.json` in the monorepo
2. runs `fossa test` to fail upon failure (previously it would only fail upon _error_)
Some theoretical schemas are not in any sort of shape Appium can use, so we now catch them as soon as possible (at the registration phase).
- adds type guard
- adds
Extensions were not correctly receiving the default values as specified in their schemas. For example, in `xcuitest` driver, the `wdaLocalPort` option has a default value of `8100`, but this value would never make it to the driver.
The root cause was that `getDefaultsForSchema()` returns a _flattened_ object (which is useful for displaying to users as part of `getNonDefaultServerArgs()`), but by the time defaults should get assigned to parsed arguments in `main.js`, the parsed arguments object has already been expanded to a deeply-nested, non-flattened object. So `"driver.driverName.argName": "value"` would be set in the args, but not `{"driver": {"driverName": {"argName": "value"}}}`. Furthermore, the properties of `cliArgs` are not prefixed with `<extType>.<extName>.`, but are just the arg name itself (which makes sense).
To address this, two main changes:
1. `getDefaultsForSchema(flatten = true)` (renamed from `getDefaultsFromSchema()`) now accepts a `flatten` flag, which will return a flat object using `<extType>.<extName>.`-style prefixes. This is useful (and less computationally intensive) for comparing defaults across the whole of Appium and its extensions. This is _not_ useful when merging defaults into the parsed arguments object, however, as that object will be deeply-nested. If `flatten` is `false`, a deeply-nested object will be returned, which is consumed by the `main` module when post-processing parsed CLI arguments and config file values.
2. Added `getDefaultsForExtension(extType, extName)` which acts like `getDefaultsForSchema(flatten = true)` _but_ only returns defaults for a particular extension _and_ strips the leading prefixes. This is used by `assignCliArgsToExtension` in the `AppiumDriver` class.
Other changes:
1. `ArgSpec` now keeps a `rawDest` property which is like `dest` w/o the prefixes.
2. Make more types
3. Re-organize `driver-specs` unit test somewhat, and update to reflect changes.
Christopher Hiller