This appears to be a bug in `json-schema-to-typescript`, where the `ipv6` type converts to `{[key: string]: unknown}` instead of `string`.
For now, we need to drop all formatting requirements from the `address` prop until this is fixed.
This did not break CI because the `build` script of `@appium/types` was run either _after_ building the rest of the project, or not at all, and the resulting change to `appium-config.ts` was not committed.
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.
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.
Jonathan Lipps