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.
The "old" way of defining tuples is `[T, U]`, but I think TS 4.7 introduced "named" tuples, which at least provides a little bit of context to consumers, e.g., `[foo: T, bar: U]`. Since a tuple is just a fixed-length array, the names aren't actually used in code, but are surfaced in type information and error messages regardless.
Also:
- Fixed bad param name in definition of `SessionHandler`
- Used a semantically-correct type for `StopScreenRecordOptions.formFields`
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 change makes Lerna execute E2E tests across two cores. Some of the slower E2E suites (`appium`, `support`, `opencv` and `base-driver`) also run in parallel via Mocha's `--parallel` flag.
In Appium, the main culprit was `cli.e2e.spec.js`, which I split into four files: `args` (argument handling), `cli-driver` (`driver` command), `cli-plugin` (`plugin` command) and `local` (behavior when Appium is a dependency). This should run faster (in theory) since Mocha runs tests in parallel _per file_ and will expand to the available cores.
CI has limited cores, so this won't really help there--but it will speed up local development. When running tests locally, you may see various delays, as Mocha buffers the output of a single test file.
This is a continuation of the work I did in #17252.
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 breaking change if someone is actually using the `npm` module out of `@appium/support`. Personally, I'm gonna go with "no"
The signature of `installPackage()` has changed from returning a parsed `package.json` to returning an `NpmInstallReceipt` object, which contains parsed `package.json` prop `pkg` and `string` prop `installPath`.
npm may have changed its behavior around installation of packages at local paths, but `npm install /path/to/thing` no longer seems to create a symlink.
the `installPackage()` method in `@appium/support`'s `npm` module now accepts an `installType` option. if the value is `local` an `npm link` will be performed; otherwise an `npm install` will be performed.
- (appium) reverted some changes I made to a test in `driver.e2e.spec.js`
- `installViaNpm` now wants an `installType` option. this is required
- removed a redundant script
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.