`lerna publish` has been acting up, and I think it's because the lifecycle scripts don't do enough cleanup, or we're running them in the wrong order, or something. so here's this.
it causes an "extra" rebuild between version and publish, but I think it's better to be safe than sorry here.
- Doc gen for:
- `@appium/driver-test-support`
- `@appium/opencv`
- `@appium/plugin-test-support`
- `@appium/test-support`
- Added a `dev:docs` script in the root monorepo. The file watcher does _not_ presently rebuild reference docs upon changes to sources (which is a limitation of `@appium/docutils`).
- Changed the `dev:docs:*` scripts in `appium` to use `appium-docs` (so it rebuilds reference docs at least once [because it runs typedoc!!])
This adds [tsd](https://npm.im/tsd) which provides a small framework around running expectations against declaration files. This is intended to be run against hand-written declarations, but because we (apparently) cannot rely on `tsc` to output valid declaration files, we should also use it to test the generated declarations of our packages.
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 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).
Christopher Hiller