Some CLI args can be interpreted as filenames or JSON/CSV blobs. Appium first assumes the value is a file and attempts to open it. But if a blob is given and it is of some _problematic length_, the OS will throw an `ENAMETOOLONG` exception trying to open a filepath with a huge blob. If the JSON is reasonably small, an `ENOENT` will be thrown instead. Previous to this change, we were only looking for `ENOENT`; now we treat `ENAMETOOLONG` errors as JSON blobs. If the problem is that the filename _is_ actually too long, the user will get an "invalid JSON" error, which will probably be confusing, but is less likely to happen than the more-common error this addresses.
If someone complains about it in the future, we can take another look, but it's going to take more effort than it's worth atm to fix it (imo).
BREAKING CHANGE:
This change upgrades to ESLint v8 and removes `@babel/eslint-parser`, which is only necessary if we're using mid-stage TC39 proposals (which we aren't). I think `@babel/core` was a peer dep of `@babel/eslint-parser`, so I removed that too. And removed cruft from the main configuration.
ESLint rules _very likely_ had breaking changes, but I didn't experience any on our codebase. However, this version of ESLint seems to be incompatible with `gulp-eslint`, so `@appium/gulp-plugins` should be held back from upgrading.
In addition:
- Updated `README.md`
- Updated some fields in `package.json`
- Loosened `peerDependencies`, as they're supposed to be loose.
This package was missing `@appium/types`, which means packages consuming `@appium/support` which _don't_ also consume `appium` in some capacity will have types that won't compile, e.g., `teen_process`.
This PR passes a `cliArgs` parameter to the static method `updateServer` of drivers and plugins so they can take action on the server configuration based on the content of the arguments.
Note that `cliArgs` is a misnomer, because these args can also come from configuration files.
Closes#17304
I'm not sure _what_ happened here other than "the types weren't strict enough" otherwise I would have noticed this earlier. Anyway; the check to see if we should dig into the config object to normalize the keys was getting passed _something_ but that _something_ wasn't anything it expected.
As a result, I needed to update some tests which assumed `readConfigFile()` resolved w/ an identity w/r/t the config file itself. It doesn't give the config file back verbatim any longer; the result will be normalized to camel-case keys (or whatever the `appiumCliDest` property is, if it exists)
* docs(appium): reorganize migration doc info so that appropriate bits are in their own docs
* Update packages/appium/docs/en/ecosystem/build-drivers.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/ecosystem/build-drivers.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/guides/caps.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/guides/caps.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/guides/config.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/guides/config.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/guides/config.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/guides/config.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/guides/config.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* Update packages/appium/docs/en/guides/migrating-1-to-2.md
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
* add header for extensions
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
This adds a test (which currently only runs automatically in CI) which installs the uiautomator2 driver. This will ensure that driver installation does not only work in a dev environment!
Due to needing to support Windows and not wishing to befoul the default `APPIUM_HOME`, we need `cross-env` as a production dependency (otherwise the smoke test would fail) to set a temporary `APPIUM_HOME` (`local_appium_home`) which is relative to the temp dir used by the smoke test (see https://github.com/boneskull/nodejs-production-test-action)
Also fix duplication of error messages about engines.
Unfortunately this adds another startup delay, but I'm unsure of a better way around it. I guess bundling our own npm might work!
Resolves#17250
This change passes any extra unknown arguments to extension scripts _if and only if_ `appium <extension> <name> run` is executed. In all other cases, unknown arguments result in an error and the `appium` CLI will abort as before.
Example:
```bash
appium driver fake run fake-success --foo --bar`
```
In the `fake-success` script of the `fake` driver, `process.argv.slice(2)` will be `['--foo', '--bar']`. Extra arguments can appear anywhere after the `appium` executable in the command and do not need to appear after the script name.
- In addition, added some missing arguments for extension subcommands to the types (`json`, `suppressOutput`). Extra arguments are stored in property `extraArgs`.
- Fixed a type problem surfaced by the previous item
- Changed help text for the `run` subcommand to hopefully read more clearly
- Reorganized E2E tests for the `run` subcommand
- Slightly changed error output when unknown argument is provided (given that we now need to DIY this)
This removes the symlink we were creating to avoid an extra install of `appium` in `APPIUM_HOME`. Using a symlink obviously breaks stuff, because (for whatever reason) `npm` wants to run lthe `prepare` lifecycle script in the symlinked `appium`, which will not work outside of a dev environment due to missing dev depenencies.
Because npm v7+'s behavior is to install peer dependencies automatically, this will cause `appium` to be installed alongside any extensions in `APPIUM_HOME`. Each extension will have its own `appium`. This may just be the price we have to pay for using `APPIUM_HOME`, or there may be another solution to avoid the extra install (I'm not sure what it is). I think it _also_ exposes us to future bugs where the running Appium differs from whatever the peer dependency is set to... which sort of defeats the purpose of peer dependencies. Either way, the user will get a warning if the currently-running Appium is too new for an extension.
- `@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`
Christopher Hiller