This patch moves fixtures.js to base.fixtures.ts that sits next to tests. All tests get an extra import to get the base fixtures (both types and implementations).
This patch:
- refactors script to output per-browser package dependencies. This is to aid with
per-browser docker setup and Playwright github action.
- sorts package maps for both Ubuntu 18.04 and Ubuntu 20.04 alphabetically (and removes a stray dependency)
References #2926
This makes it easier to reason about our packages.
The only difference is what each package downloads.
When the browser is not downloaded, it will fail to launch.
Each browser gets a 'download' attribute in the browser.json file.
We now commit protocol.ts files during the roll.
New utils/roll_browser.js helps with that.
This makes our installation very shallow:
- build installer;
- download browsers.
This patch:
- makes environment a simple class with optional methods `beforeEach`, `afterEach`, `beforeAll`, `afterAll`, `globalSetup` and `globalTeardown`
- removes capability to have multiple hooks of the same name inside suite
- removes default environment for test. (`dit` now adds a `TraceTestEnvironment` to the test)
- extracts all environments that we use in our tests in `//test/environments.js`
Downsides:
- we no longer know hook locations for the environments. This, however, should not be a big deal since stack traces (if any) will still point into it.
- this also regresses hook locations for suites for simplicity. We can get them back, but it shouldn't be pressing since we now have only one hook of each kind in every suite.
This patch:
- drops dependency on playwright-core in all our packages. Instead of
the dependency, packages are now built with `//packages/build_package.sh`
script.
- unifies `browsers.json` - now there's a single `//browsers.json` file
that is used to manage browser revisions.
This patch temporary switches canary publishing to `--dryn-run` from CI/CD so that we
can verify that it does sane things.
We'll unify all our package management scripts under `//packages/` in a
follow-up.
Fixes#2268
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.
This encapsulates selectors logic in one place, in a preparation for more complex scenarios like main-world selectors or piercing frames.
Note: we had `Page.fill should wait for visible visibilty` test, but we do not actually wait for visible in page.fill(). It happened to pass due to lucky evaluation order.
References #1316.
Adds logging comments to the doclint tests, and adds a new one with a bulleted list in a comment. Lists can only be used in comments where extra properties would be unexpected.
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.