I noticed we were filling up our allotted cache space. Reading about it, I found this example to cleanup caches we no longer need (specifically, from closed PRs)
What used to be the `generate-docs` script no longer works, since the `commands-yml` directory no longer exists.
Unclear to me what should be done here at this point, but it makes the "build command documentation" job pointless.
This replaces use of GH action `boneskull/nodejs-production-test-action` with direct use of `midnight-smoker`. It's now trivial to run all the smoke tests in a development environment.
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.
This is a "fix" but only for the dev environment.
Further:
- add install of `mjpeg-consumer` to CI, since it may have disappeared from the environment
- remove `overrides` from `@appium/support`'s `package.json` since it no longer seems needed
- `e2e-test` is now `test:e2e`
- removed `pre`/`post` lifecycle scripts because it's hard to parse what's happening
- in CI, e2e tests do _not_ run in parallel, no extra build occurs, no types are built, and no lint happens. (types/lint happens in a diff job, and there aren't enough cores available for parallel mode to make a difference)
- removed a bunch of scripts to test individual packages. you can just `cd packages/<pkgname> && npm t`
Most of these changes are the addition of types. There are a few places in which the typechecker found weirdness, and I have addressed those.
- In `logging.js`, `parseInt()` was being called on props of `process.env`; this is not allowed, because `parseInt()` only accepts a string, and props may be `undefined`.
- In `log-internal.js`, I had to remove the `raiseError()` function because TypeScript is unable to understand that a function, when called, will always throw. The fix was just to replace with `throw new Error...`
- Introduced a var in `mjpeg.js` to avoid repeated casting
- Added some type guards to `net.js`. as function parameters, union types kind of suck. This is definitely one place TS would have helped, since it allows function overloads. Also dropped use of deprecated `url` module in lieu of W3C `URL`.
- Removed some old-node-version cruft from `util.js`.
Non-code changes:
- Needed to use an override for `type-fest`, as it's included as a transitive dependency, but otherwise is only present in the devdeps of the monorepo root `package.json`. This means, due to version conflicts, a `support/node_modules/type-fest` would be created with an old, incompatible version, which would be preferred over the monorepo one due to Node's resolution algorithm. This needs npm v8.3+ to work properly, but is only a problem for contributors (not consumers).
- Pinned type of `opencvv-bindings`.
- No longer deleting `build` dir before transpilation since it may contain generated declarations!
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 PR moves the FOSSA check from the Node workflow to its own. It won't run if the API key secret is not present (which would be true when running PRs from forks).
In addition, the check
1. will only run on changes to any `package.json` in the monorepo
2. runs `fossa test` to fail upon failure (previously it would only fail upon _error_)
Christopher Hiller