This strictly defines Firefox build folder as `obj-build-playwright`.
Currently, Firefox build folder encodes current Mac OS version including
patch versions, and thus we might end up with multiple different build
folders.
This generates typescript definitions based on the api.md, instead of autogenerating them from the typescript source code.
Now types
- only include the public api
- work with older versions of typescript
- include descriptions
- are more consistent
- are more complete
#6
This patch:
- removes `browserType.downloadBrowserIfNeeded()` method. The method
turned out to be ill-behaving and cannot not be used as we'd like to (see #1085)
- adds a `browserType.setExecutablePath` method to set a browser
exectuable.
With this patch, we take the following approach towards managing browser downloads:
- `playwright-core` doesn't download any browsers. In `playwright-core`, `playwright.chromium.executablePath()` returns `null` (same for firefox and webkit).
- clients of `playwright-core` (e.g. `playwright` and others) download browsers one way or another.
They can then configure `playwright` with executable paths and re-export the `playwright` object to their clients.
- `playwright`, `playwright-firefox`, `playwright-chromium` and `playwright-webkit` download
browsers. Once browsers are downloaded, their executable paths are saved to a `.downloaded-browsers.json` file. This file is read in `playwright/index.js` to configure browser executable paths and re-export the API.
- special case is `install-from-github.js` that also cleans up old browsers.
Currently in our API `?` means null, but sometimes it means optional. Linting optional/nulls with this patch is required for #1166 to land nicely.
Previously, return types were not being linted in `api.md`. This is fixed, along with many broken return types.
This patch considers `?` to mean nullable, and has some heuristics to determine optionality. I believe this to be the minimal patch needed to unblock #1166. After it lands, we can consider changing the api docs to hopefully remove some heuristics and strangeness.
We do not guarantee that click resolves before load event comes.
Theoretically, inserting two tasks before resolving load should help,
but seems like a strange contract.
Drive-by: move auto waiting tests to a separate file.
