This is getting pretty close, but:
- Commands from a driver will show even w/o a `newMethodMap` or `execMethodMap`; it is able to understand that it's overriding `BaseDriver`
- It's also able to understand the associated routes
- And it's able to understand the routes even if `BaseDriver` does not implement it
Still working on the parameters display, but we have the name override working at least.
Added some docstrings in `fake-driver`, `base-driver` for testing
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
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.
- update flattened schema fixture to match actual schema
- plugin/driver e2e tests were also busted
NOTE: test that checks for a symlink when doing a local install is _not_ passing in CI and I cannot reproduce locally. I have disabled the test for now.
This uses the [boneskull/nodejs-production-test-action](https://github.com/boneskull/nodejs-production-test-action) GH action to run a smoke test across all packages.
The action does the following:
1. Runs `npm pack` on each package, writing the tarball to a temp dir. This tarball contains the package as a user would `npm install` it.
2. Changes into the temp dir and runs `npm install <tarball>` on each
3. Runs a specified script (in our case, `test:smoke`) in each installed package's dir in `<tmp_dir>/node_modules`
Because `devDependencies` will not be present, this should avoid a class of issues where production deps are miscategorized as dev deps.
The action should probably use a separate temp dir for each--in the case of a dependency being present but only because some other package depends on it--but it's not smart enough to figure out peer dependencies yet.
Resolves#16924
Because the `postinstall` script of `appium` needs functions in `@appium/support`, that module must be compiled _before_ its `postinstall` script runs. Prior to this PR, only the monorepo root would run a `postinstall` script to build the subpackages. Now, each package has a `prepare` script which runs its own build; this happens prior to any `postinstall`. This way, the `postinstall` script in `appium` can run successfully.
`@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`
Jonathan Lipps