* feat: move logger into appium/logger
* add logger in tsconfig.json
* add smoke with loading the index.js
* modify files to fit other modules
* refer to @appium/logger
* update with npm run sync-pkgs and a few
* cleanup changelog and package-lock.json
* update smoke
* pin deps
* adjust tsconfig.json with others
* Update README.md
* update license
* update license
* Update LICENSE
* fix review
- Adds a "Run Appium" launch/debug config
- Fixes the "Run Current File" launch/debug config
- Fixes the monorepo's root TS config to handle requiring `ts-node/register` when `mocha` bootstrapped via `node`. _`node`_ must require `ts-node`; not `mocha`.
Closes#17895
This pulls in some recommended settings from `@tsconfig/node14` (a proper TS target configuration for Node.js v14; ours wasn't _wrong_ per se, but this is better) and allows us more flexible use of `ts-node`. Use of this module is recommended by `ts-node` (which we need to run tests).
`ts-node`'s behavior changes _depending on the directory in which it's run_--and this can cause some really nonsensical bugs--so the changes here ensure that it will act the same regardless of if you're running tests from a package directory or the monorepo root.
Also:
- Ensure various `clean` scripts don't fail if they've been run before `build`
- Enable `strict` mode in `@appium/types` cause we can
- Fix a type issue found in `@appium/support`; this does not appear to have been a traditional bug but rather a type disagreement surfaced by the new config
# Conflicts:
# package-lock.json
# packages/typedoc-plugin-appium/tsconfig.json
- `@appium/gulp-plugins` does not use `tsc` and continues to use...whatever it uses.
- `@appium/doctor` now has generated declarations, though I didn't bother to do anything with the types
- rewrote swaths of build scripts:
- removed the `fix` and `lint` scripts from each workspace (package) since I don't think they get used and they are of limited value
- for tests and autoinstallation of extensions, added `ts-node` for on-the-fly compilation
- workspaces _can_ define their own `build` and `clean` scripts (both should be required if either is used). these do not currently get run when running `npm run dev`, but they do occur on a bare `npm install` from the monorepo root or a `npm run reinstall`.
- `npm run rebuild` does a fresh rebuild, but does not clean any `node_modules` dirs nor does it reinstall anything.
- removed `prepublishOnly` since `preversion` does the same thing
- `npm test` now runs `build`/`lint` in parallel
- postinstall script of `appium` ("autoinstall") script now must call `npm run build` if in a fresh dev environment. this is because a) lifecycle scripts of packages run before lifecycle scripts in the monorepo root, and b) `postinstall` runs before `prepare`. so there's really no way around it; even using `ts-node` fails because other modules depend on `@appium/support/index.js` which expects the pkg to be built.
Closes#17746Closes#17807
This is a typedoc plugin based on `typedoc-plugin-markdown`.
It outputs everything that plugin outputs _plus_ it outputs information about commands (API endpoints) as defined in drivers, plugins, and the builtins in `@appium/base-driver`
It's written in TS because that was the easiest way, because a) there was some sort of disagreement between Babel and TS re: exports, and b) everything it's built on is written in TS.
Run `npm run typedoc` to generate docs in `typedoc-docs` dir.
I thought I'd take a few mins and set this up. It was _mostly_ straightforward, except:
1. Figuring out the "entry point" for each package was difficult until I realized `.js` entry points are assumed to be compiled, and thus require a `sourceMappingUrl` reference. IMO this is probably a bug in TypeDoc
2. The `sourceMappingUrl` must reference an external sourcemap file; not an inline source map. If it's an inline source map, the system tries to `fs.open` a large data-url.
3. The babel config does not control whether external sourcemaps are created; `@babel/cli` does. So I needed to change those.
4. Practically speaking, I don't see any drawback to external sourcemaps _yet_
5. TypeDoc has poor support for cross-package type references in monorepos, and I had to add a plugin which implements a workaround
6. Per some suggestions in the docs, I modified the order of references in the root `tsconfig.json` to start with "the biggest one first"
I didn't modify any types or docstrings anywhere.
The big idea here is:
1. `desiredCapConstraints` should always contain the constraints _for that driver_; it no longer contains the "base" constraints. This is the only thing that really required any logic changes (though they are somewhat spread out). The "merged" constraints object is available via `_desiredCapConstraints`.
2. `Capabilities` and W3C-style `W3CCapabilities` are now _derived from_ constraints. This absolves us (and extension authors) from needing to create an interface describing their capabilities.
3. Changes to caps and constraints now reflect in `DriverOpts` (`this.opts`) in drivers
4. `caps` and `originalCaps` declarations have moved from `Core` to `Driver`
5. TypeScript compiles the JS output from `@appium/types` (which is just a static "constraints" object)
Resolves#17518
- `@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`
The peer dependency value is stored in the `extensions.yaml` manifest for each extension as `appiumVersion` (if present).
If the peer dependency is _not_ present, the user will be warned, but Appium will still try to load the extension (I have a feeling that most of the time, this will be fine). When warned, the user will receive information about available extension upgrades, if any.
This required some refactors in the `lib/extension/` dir. Extension validation was previously a synchronous process, but because we now (potentially) display information to the user about upgrades (which is async), validation must also be async. This means that the `ExtensionConfig` constructor (and the constructors of its subclasses) cannot run validation. Validation must happen after the config object is instantiated, which is handled in `loadExtensions()` of `lib/extension/index.js`. The constructor signatures have changed accordingly.
While extensions now soft-require a `peerDependencies.appium` field, in the monorepo, the value of this dependency is `file:../appium`. This is treated as a special case, and acts as if the dependency is just the current version of `appium` (as in its `package.json`). This is handled in `Manifest#addExtension()`.
To further support this, `appium` now exports `@appium/base-driver` as `driver`, `@appium/base-plugin` as `plugin`, and `@appium/support` as `support`. `tsconfig.json` files have changed in these affected packages.
In addition, a new reusable TS config file has been added for use with basic plugins.
# Conflicts:
# .eslintrc
# packages/appium/lib/extension/extension-config.js
# packages/appium/lib/extension/index.js
# packages/appium/lib/extension/manifest.js
# packages/appium/test/unit/extension/manifest.spec.js
# packages/appium/test/unit/extension/mocks.js
yeah this is my bad. if we really need the history I can redo this.
no significant changes; just the usual stuff about builds and types.
bonus: I figured out how to get webdriverio types working
`@appium/schema` is a package which was extracted from `appium`. It _only_ contains the schema. The impetus here was to avoid cyclical dependencies, since `appium` depends on `@appium/types`, and `@appium/types` depends on the schema. This package breaks the cycle.
The `scripts/generate-schema-json.js` (which converts the compiled JS schema file into JSON) has moved into this package, and the generated JSON file is now under version control. This is because the `generate-schema-types.js` script (previously `generate-schema-declarations`) depends on it, and `@appium/types` depends on the generated types. The generated types are _also_ under version control. I do not expect the schema to change often, so I believe the tradeoff to be worth it.
## @appium/schema
`lib/appium-config-schema.js` is the "single source of truth" for the schema.
## appium
- Removed schema source
- Removed namespaces from internal types because they suck (see change to `types/index.d.ts`)
- Removed unused `continuation-local-storage`
- Add dep for `@appium/schema`
- Added a TS project dependency on `@appium/schema`
## @appium/types
- The "sources" have moved from `src` to `lib` for consistency.
- `lib/appium-config.ts` (the generated types) are now under version control.
- `lib/schema/` has been removed (it previously held the JSON schema artifact)
- `scripts/generate-schema-declarations.js` becomes `scripts/generate-schema-types.js`
- Updated scripts in `package.json`
- Added dep for `@appium/schema`
- Added a TS project dependency on `@appium/schema`
## Other
- Reorganize root `tsconfig.json`; add `schema` reference; remove unused `noEmit: true`
- Sort root `package.json`
- Remove schema JSON and schema declarations scripts, since those are now both handled in their respective packages
- Remove `lint-staged` config for schema file, since it didn't work right anyway (still need to do something about this, but probably doesn't need to be in a precommit hook)
- Remove stuff from `.gitignore`
* feat(appium): generate declaration files
Configure TS to generate declaration files for `appium` package.
Most of these changes are just types getting added or changed via docstrings; in other places, typechecking has caught problems and I had to refactor code to address them.
- Removed `// @ts-check` pragma from all files in `lib/`, since now `checkJs: true` is in `tsconfig.json`. It needs to stay in place elsewhere (I think) because only sources in `lib` have declarations generated.
- The `install`, `uninstall`, `update` and `run` functions in the base `ExtensionCommand` class were renamed and prefixed with a `_`; TS does not allow overridden functions with differing signatures. It no longer exports a default.
- Removed `type` prop of options for `DriverCommand` and `PluginCommand` constructors, respectively (this value is derived from the `ExtensionConfig` `config` parameter instead)
- `AppiumDriver` now extends `DriverCore` instead of `BaseDriver`, since some of its function signatures differ from `BaseDriver`'s.
- Small refactor of `deleteSession` to make typechecker happy.
- `executeCommand` now calls to `BaseDriver` directly if `isUmbrellaCmd` is truthy. This is one place where inheritance just kind of breaks, since `BaseDriver#executeCommand` returns something entirely different than `AppiumDriver#executeCommand` would otherwise.
- Removed `--delete-dir-on-start` from build command, since it may blast generated declarations.
- Reorganize declarations in `types/`; moved some of them out of `@typedef`s. `types.d.ts` becomes `index.d.ts`
- Note that this contains the declarations for `PluginClass` and `DriverClass`, which correspond to the types of extension "main" classes. This differs from the interfaces provided in `@appium/types` (e.g., `Driver`, `ExternalDriver`) in that these aren't just objects; they are classes with constructors and static members. I may end up moving some of this stuff into `@appium/types`, but I'm not sure how useful it will be. Will see when I add types to `@appium/fake-driver`.
* chore(appium): remove transpile directives
this was ostensibly for gulp-babel
* chore(appium): remove redundant type declaration
* fix(appium): avoid potential unhandled rejections
- make types more readable
* chore(appium): fix capabilities types
- move `scripts/generate*` elsewhere
- add reference to `@appium/types` in `tsconfig.json`
* chore(appium): review updates for legibility
This was not as easy as the other two. The main issue involves the `BaseDriver` class and is threefold:
1. `BaseDriver` and a valid external subclass thereof (a `Driver`) are not the same, because the former is essentially _abstract_. There is no notion of an abstract class in JS nor in TS for JS.
2. Splitting `BaseDriver` into several modules and "mixing in" some modules is just not well-understood by TS.
3. `AppiumDriver` inherits _most_ of `BaseDriver`, but overrides some functions with differing signatures. This is unsupported by TS.
To work around these problems, I had to:
1. Move the `Driver` interface into `@appium/types`, since other packages may depend on it. We do not want circular dependencies, which is likely to occur otherwise. Further, there is no way to tell TS for JS that a class _implements_ an interface or type.
2. Refactor the mixins (in `basedriver/commands/`) into "mixin classes", as understood by typescript. These are dynamic classes returned by functions which accept a class parameter, and _extend_ that class. The result is marginally better, but the implementation is ... well, see for yourself. It is not possible to use declaration merging to just "trick" TS into thinking that `BaseDriver` has all of these extra methods; classes cannot be merged, and even if you could, you can't use declaration merging to "add" methods afaict.
3. `BaseDriver` is now an empty class which inherits from all mixins applied to `DriverCore`. Due to syntactic restrictions, it must be a `class` statement in order to use the `@implements` tag, which causes TS to check that the result fully implements `Driver`. `AppiumDriver` _also_ inherits from `DriverCore`, since it does not override `BaseDriver` "properly". `BaseDriverCore` itself is pretty small, containing only those functions which `AppiumDriver` defines as differing.
Otherwise:
- `BaseDriver` does not inherit from `Protocol`, which is just an empty class. `Protocol` was removed.
- All of the error classes are exported from `protocol/errors`, because TS cannot see them otherwise.
- Exported missing `GET_STATUS_COMMAND` from `protocol/index`
- Re-exported `normalizeBasePath` from `server` instead of `protocol`, since that's where it's defined
- Removed `index.d.ts`
- Mixins use `@implements` as well. Note that `@implements` does not support `import('..')` syntax.
chore(base-driver): attempted to make types for mixins less awful
fixed a couple issues in the types in `driver.js`
core(base-driver): add capabilities types
- also move the bluebird config into the index
- fix references to `DriverOpts`
- add `assignServer()` to `BaseDriverCore`, used by `AppiumDriver`
chore(base-driver): fix more types
add missing reference to `@appium/types` in `tsconfig.json`
fix(base-driver): ensure getLogEvents is async
fix(base-driver): add some more type checks and fix logCustomEvent to be async
chore(base-driver): reformat
This changes the TS configuration to to a) emit declarations for supported packages, and b) build declarations incrementally by package.
To begin, we are targeting `appium`, `@appium/base-driver` and `@appium/support` for declarations; these three are intended to be published with declarations generated via their JS.
Both `@appium/support` and `appium` are fully typechecked (sans implicit `any` types), but `@appium/base-driver` is mostly not. Regardless, declarations are generated for all three.
Each package will have its own `tsconfig.json` which "inherits" from `config/tsconfig.base.json`. Each will also need to declare relative paths to dependencies. e.g., the `appium` package must configure its `tsconfig.json` so that it depends on the declarations of `@appium/support` and also where to find `@appium/support`. Essentially, a small dependency tree gets built, and those at the "root" get their declarations built first; then the consumers use those declarations.
Also reorganized some scripts and added `npm-run-all` to help and added a "typecheck" job to CI.
Since `npm install` will build, it's pretty inconvenient to have `npm` abort installation if the build fails. In that case, if any of the build steps fail (see `build:loose`) the installation will continue. Added a `prepublishOnly` which runs a build in "strict" mode where everything must pass.
_Note: there's still a strong coupling of "what `BaseDriver` provides" and "what an external driver *may* provide". It's unclear to me if this is a problem, though there seem to be a handful of methods that external drivers *must* implement. The easiest way to get around this would probably be to extract these required properties and methods into their own interface (duplication) if we cannot otherwise declare methods as "abstract". As it stands, the `Driver` is basically just `BaseDriver`._
Also:
- Moved some configuration types out of `appium` and into here, since they are used both by `appium` and `base-driver` via `DriverOpts`
- Split `Driver` type into "the thing that BaseDriver is" and "all the other methods external drivers can implement"
- Added missing `proxyCommand` method
- Better generics for `LogType`
- Remove unused `Constructor` type
- Better types for `getSession`/`getSessions`
- Added util `Class` type
- Added many missing typings from DefinitelyTyped
- Added `ts-node` for `@wdio/types` (I need to send a PR to webdriver to eliminate this dependency)
- Type checks in their CI step
This change removes `gulp` and replaces it with plain ol' `babel` and `mocha`.
## `appium`
- No gulp.
- `test/` has been re-organized. All test files now end in the extension `.spec.js`, which is a recognized convention and understood by editors/IDEs. The tests are further split into `unit` and `e2e` subdirs. This makes working with both `babel` and `mocha` easier.
- The tests are _not_ run against the transpiled code; code is now transpiled on-the-fly via `@babel/register`. This only affects `appium`.
- `commands-yml/validator.js` moved to `scripts/parse-yml-commands.js`. It has been rewritten as a CJS module. `commands-yml/` should not contain `.js` files.
- `test/setup.js` is a new test harness specific to Appium, which loads & configures `@babel/register`. Eventually, the contents of this file can be moved into the root monorepo's `test/setup.js`, but the rest of the packages do not need `@babel/register`, so we avoid the overhead.
## `@appium/gulp-plugins`
- Unfortunately, due to the new `npm test` strategy (see below), we cannot use the `nyan` reporter. Or rather, we _can_, but will not see the animation. So the reporter is now set to default to `spec`.
- Modified tests so they didn't overwrite the actual `build` dir with transpiled fixtures, which is what was happening. This was causing failures depending on the transpile/test order.
## All Packages
- All packages now have their own `build`, `test`, `test:e2e` and `dev` (just build + watch mode) npm scripts. This makes running a complete build easier, since each package can now provide its own appropriate command. This is _mostly_ just `gulp once` (where `gulp` was used before), except for `appium`, where `@babel/cli` is used directly.
- This is what happens when `npm test` is run from the monorepo (in order):
1. All packages are built (in parallel) by running `npm run build` in each folder (via `lerna`). See `pretest`
2. All code is linted directly via `eslint`.
3. All _unit tests_ are run w/ `npm test` in each folder, having assumed transpilation already occurred (if necessary).
- `npm run e2e-test` runs the `npm run test:e2e` in each folder. No transpilation occurs! Careful.
- All scripts are expected to live in `packages/*/scripts`, and this directory enforces CJS via ESLint. `postinstall.js` moved, as well as `check-npm-pack-files.js`. `generate-schema-declarations.mjs` moved from the root `scripts/` dir into `packages/appium/scripts/`; it's now CJS instead of ESM.
- I had profiled running various things with `lerna run --parallel`, but it turns out this is not faster. I'm not sure why, but I think it may have something to do with streaming STDOUT/STDERR, or potentially the overhead of running child processes outweighs the time it takes to actually run tests and builds.
- The behavior of `lerna run` now mimicks `lerna exec`, which was "run stuff in serial, streaming the output". The default behavior of `lerna run` is "run stuff in parallel, buffering the output". Buffered output sucks, and streaming the output from all tasks at once creates chaos. To override this behavior, you'll see `--parallel --concurrency=8 --prefix` for tasks that can truly be parallelized, like transpilation. The number 8 is the "maximum", and CI usually won't have more than 2 cores available anyway.
- When run in CI, Mocha runs with `--forbid-only`, which will fail if there's an `.only()` somewhere in the tests. Further, it forces color output.
## Etc.
- Updated Wallaby config, `.gitignore`, `.eslintignore`.
- Sorted `package.json` files
- Removed `watch` and `coverage` scripts which were broken anyway.
chore(appium): fix schema json path issues
- the path to the JSON schema is now correct: `lib/appium-config-schema.json`
- add `log-symbols` to devdeps for niceness. this is already a transitive dep
Logging was happening here before the logger was properly initialized, which looked weird. Just remove logs for now until we find a better solution.
In addition, fixed some typing problems:
- we need `@types/node` for node globals (like errors that have a `code` property)
- set various typings as globals: `node`, `mocha`, `chai` & its ilk
- revert changes to default boolean values
- fix types w/r/t the object returned by `parseArgs()`
- `.d.ts` files _and_ `.js` files can now be checked via `tsc` (given typescript Version 4.6.0-dev.20211102 or newer); remove `jsconfig.json` in lieu of `tsconfig.json`. js files will only be checked if `// @ts-check` pragma is present
