In certain situations in `.ts` sources, class definition lines can get very long. Prettier will split these into multiple lines, and add a final line with `{` at position 0. This conflicts with the `brace-style` rule in ESLint. I am not sure why the ESLint prettier config doesn't already handle this, but I am going to guess it's because that config doesn't work on `.ts` sources.
BREAKING CHANGE: This makes `@appium/eslint-config-appium-ts` also apply to JS sources _and_ requires a new peer dependency (`eslint-import-resolver-typescript`). The `main` file is now a `.js` file. The module is expected to _extend_ `@appium/eslint-config-appium`, not replace it; consumers needn't extend both in their ESLint config.
In the not-too-distant past, `@typescript-eslint/parser` was unable to understand docstrings in `.js` files. Evidently this is no longer true.
I've rewritten and heavily commented the configuration explaining the intent behind everything.
This change ensures when running `mkdocs` or `mike` with the `--serve` flag, the output is unbuffered and stdio is inherited from the parent process.
This will show helpful things like _the URL at which the development server is running_.
Currently there is no way to specify a log level when running extension commands (e.g., `appium driver list`). Further, the log level used by the support module depends on whether or not Appium set it; used outside of an Appium context, there is no way to programmatically set the log level of the support module via an external API.
To that end, I just removed the log messages, because a "proper" fix will be quite involved. See #16970.
This change makes it so when running an extension script (e.g., `appium driver foo run some-script`), unless the `--json` flag is present, the child process will do no buffering whatsoever and will inherit `process.stdin`, `process.stdout` and `process.stderr` from Appium.
This means that extension scripts can do stuff like prompt the user for input. It _also_ means they can do stuff like display progress bars and spinners.
If the user wants JSON data, we revert to the old behavior, which is to buffer the output and dump it once the script has completed.
This adds a new package which consumers having TS sources can use. This does not affect current users of `@appium/eslint-config-appium`.
Due to the nature of TS, it can be a little more bold with fixes (e.g., changing let to const). I changed the following rules from the recommended settings:
no-empty-function: Reduced to a warning. It's likely we want the functions, but perhaps they should not be empty.
no-empty-interface: Disabled; we use these to merge mixin interfaces with driver classes.
no-explicit-any: Disabled; while transitioning from an untyped codebase to a typed one, we still need to use any in places. Eventually these should all be replaced.
no-non-null-assertion: Disabled; This allows us to continue use of the ! operator, which is handy when working with untyped or loosely-typed code (especially in tests).
no-var-requires: Reduced to a warning. Occasionally we may need to use require() instead of import.
Since the configuration extends our shared config, the following rules have been disabled:
import/no-unresolved: The eslint-plugin-import module cannot resolve TS modules.
no-unused-vars: This rule conflicts with typescript-eslint's rule, so it must be disabled per the documentation.
promise/no-native: In our TS-based packages, I haven't needed Bluebird, so it doesn't make sense to require it.
require-await: TS is much more aware of the return values of functions; this is not needed to avoid ambiguity (in TS code).
The main thrust of this was to resolve#18269.
Implementation-wise, we have to modify an `IntrinsicType` of which both `void` and `undefined` become. To make it `null`, we must create a new `LiteralType` (`null` is not an "intrinsic" type; I don't know why). I would think that TypeDoc wouldn't go around creating new `LiteralType`s every time it sees `null`, but I don't see it doing anything else. Anyway, if there is a "type cache" somewhere, I'm not sure how to get at it.
Additionally, the new reflections created for parameters and the call signature were not being "registered" properly with TypeDoc. So this adds a `static create` to both `CommandData` and `ExecMethodData` which wraps the constructor for each, respectively, then performs the registration. This keeps a `Context` object _out_ of `CommandData`/`ExecMethodData` instances (it would only be used once at time of instantiation anyway).
Un-memoized a couple methods in `BaseCommandData` since not necessary
This will automatically label PRs. We can update it to further automatically label issues at a later time, if necessary.
I have added labels for each package.
Christopher Hiller