apparently the "files" prop does not take into account what the ".npmignore" file says, so these were still getting published.
hopefully this will fix it.
The "old" way of defining tuples is `[T, U]`, but I think TS 4.7 introduced "named" tuples, which at least provides a little bit of context to consumers, e.g., `[foo: T, bar: U]`. Since a tuple is just a fixed-length array, the names aren't actually used in code, but are surfaced in type information and error messages regardless.
Also:
- Fixed bad param name in definition of `SessionHandler`
- Used a semantically-correct type for `StopScreenRecordOptions.formFields`
Contains significant changes to comment derivation.
Given a command method in an external driver, these changes cause the plugin to search a) the method itself, b) the method's signature (which may come from `BaseDriver` or even `DriverCore`), the method map, and the `ExternalDriver` interface for comments (in that order). It picks the first "summary" / "description" found, but otherwise it will _merge_ any and all block tags found, given the same precedence. So if, for example, a `@see` tag exists in cmd method `ExternalDriver.foo()` but not in `MyDriver.foo()`, the plugin will find that `@see` tag and put it into the data to be rendered by the theme for the command associated with `MyDriver.foo()`.
This also works with `@example`, with a change: the examples side-step the usual rendering (by `typedoc-plugin-markdown`'s theme; this is due to tight coupling and complexing necessary in overriding the default behavior by simply adding an overriding template or partial), and are rendered per-language (since it's likely/expected that each method will have examples in several languages). The language of the example is detected via the _fenced code block_ as used in the example. In markdown, we're currently using some headers to split examples up, but we also render a token as an HTML comment which can be used on the `mkdocs` side of things to detect the example and perform further post-processing (e.g. as a set of tabs).
If a command has examples, the examples will be surrounded by (in addition to headers for each language) this token pair:
```html
<!-- BEGIN:EXAMPLES -->
...
<!-- END:EXAMPLES -->
```
Each language's fenced code block is surrounded by the following token pair _within_ the above pair:
```html
<!-- BEGIN:EXAMPLE lang=$lang -->
...
<!-- END:EXAMPLE -->
```
...where `$lang` is the _proper name_ for a language, e.g., `JavaScript` or `Ruby`. The fenced code blocks themselves remain unchanged and will contain the "identifier" for the language, e.g., `js` or `javascript` or `rb` or `ruby` (i.e. they are _not_ normalized).
Also:
- changed the type of `KnownMethods` to be a `Map<string, CommandMethodDeclarationReflection>`, as the value of the `comment` prop is better derived via `deriveComments()`. This changes `findAsyncMethodsInReflection()` as well
- memoized `AppiumPluginLogger.createChildLogger()` to avoid creating identical loggers
- renamed `ProjectCommands.empty` => `ProjectCommands.isEmpty`
- `CommandReflection`'s `constructor` now expects a `log` parameter
- Hopefully easier-to-understand verbose logging
It sucks to run the "autoinstall extensions" script in CI or the monorepo due to the order in which lifecycle scripts are executed: the `postinstall` script of `appium` will always run _before_ the `prepare` script in the monorepo root. This completely disables the behavior if Appium has not yet been built.
Due to problems where multiple versions of `@wdio/types` can be installed in the dep tree of external modules, and the fact we are not using most of the types we pull in, it makes sense to remove this module.
The "standard" W3C caps have been pulled out of `@wdio/types`. We do not need any webdriverio or vendor-specific cap types. Those only make sense when consuming wdio itself and/or writing client-side code.
This will also make it easier to upgrade `webdriverio`; it too depends on `@wdio/types`.
Note: there were several Appium-specific caps in `@wdio/types` that I did not recognize. Perhaps these were driver-specific and not accurately labeled as such. Driver-specific caps belong in drivers.
`PluginCommand` and `DriverCommand` both conflicted with `PluginCommand` and `DriverCommand` in `@appium/types`. The former are string literals representing CLI args; the latter represent methods on plugin and driver classes.
This renames the former to make it clear it's CLI-specific
Sorting is handled by typedoc and it supersedes whatever we do with it. The correct way to implement a custom sort would be...something else. YAGNI for now
I'm unsure about a) where the filename I just changed came from, and b) if we have control over the filename, and c) if so, how much control.
But anyway: it seems to generate a file named `appium_base_driver-1._appium_base_driver.md`.
This is either a bug in the plugin or a bug in `@appium/base-driver` (tbd). But it was causing `typedoc` to fail with a fatal error, and we don't want that to happen (yet). This change punts on the problem to get the docs build working
The typo caused the `keywords` field in `packages/typedoc-plugin-appium/package.json` to be overwritten. Because of this, the `keywords` field lost the magic keyword that `typedoc` uses to automatically detect a plugin. Thus, `@appium/typedoc-plugin-appium` could not be found, and its specific options caused `typedoc` to fail.
Jonathan Lipps