This patch:
- teaches test runner to understand custom argument spelling, e.g. `--file=evalu` and `-j10`
- fixes `--file` filter to actually focus file paths instead of focusing
all tests with given path
There are a few places in the API where we use objects as maps. This patch adds them to docs and the types.
For `env`, we accept booleans and numbers as well because they are often used for their string values.
As of today, we have tooling in place that makes sure that our
main README.md **roughly** represents the state of the last release:
- browser versions and browser badges are those that we released last
- links to our API point to the last-released API version
This tooling, however, relies on the fact that every release is a sequence
of two consecutive commits:
- one commit that sets `package.json` version to a released version
- the following that "bumps" version to `-post`.
This release process is very unfortunate, because:
- it made releasing from branch impossible
- it required "freezing" commits to the master branch
This patch removes all the tooling and transitions `README.md` to always
represent tip-of-tree state. We will fully rely on
`https://playwright.dev` to show versioned docs.
This patch:
- removes releasing from Travis CI
- sets up a new GH Action that releases @next version from tip-of-tree
Once this GH Action proves to be working, we'll setup a `publish_release.yml`
workflow that will be triggered only by **release** github events
and that will publish released version with `LATEST` tag.
NOTE: this workflow does not actually run publishing - we're doing
`--dry-run` for now to see how it works in
`//utils/publish_all_packages.sh`.
This ensures we get a proper error when something goes wrong. Should
also help with producing the right error code in the case of internal error.
Drive-by: fix location issue which manifests on the bots.
Drive-by: remove the use of Array.prototype.flat to make it work on bots.
I was playing around today with different ways of changing the way we export types for #1439. I looked at only exporting 'Parameter' types, only exporting 'Return' types, only exporting a manual list of 'important' types. They all had different pros and cons, and it was very difficult to settle on a good answer.
For now, let's not export any parameter/return types. We can whitelist some types upon user request. I'm thinking `LaunchOptions` and `AccessibilitySnapshot` could be quite useful. We can always add new types after 1.0, but we can't remove them.
The patch looks funny because this was my original intent for the types, but I didn't know I had to `export {}` to tell typescript that my .d.ts shouldn't export everything.
