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.
Currently it was leading to an error if I tried to build it with a root user on a Linux environment. So in the end the type generation was just skipped:
```
22:51:55.757 $ node install-from-github.js
22:51:55.813 Building playwright...
22:52:14.094 chromium downloaded to /11994741/playwright/.local-chromium/linux-747023 22:52:14.123 Failed to launch browser!
22:52:14.123 [0310/215214.121201:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
22:52:14.123 TROUBLESHOOTING: https://github.com/Microsoft/playwright/blob/master/docs/troubleshooting.md
```
Maybe we should also exit the script with an error code if the protocol generation was not successful.
This change introduces a TestWorker that can be in a certain state,
meaning it has run some beforeAll hooks of a certain test suite stack.
TestWorker can be created at any time, which allows for a number of features:
- don't run hooks for suites with no runnable tests;
- smarter test distribution (and possibility for variuos strategies);
- recovering from hook failures and test failure by creating a new worker;
- possible isolation between workers by running them in separate environments.
This patch sets continuous deployment of playwright packages
from tip-of-tree. These packages are released under the "@next",
so it should be possible to install tip-of-tree version of Playwright
from NPM using
```
npm i playwright@next
```
A few technical details:
- This uses travis to drive deployments
- This deploys from master and only if all browsers pass all tests on linux
- This is an attempt to deploy just two packages: `playwright-core` and `playwright-firefox`. If this works out, I'll follow-up with other packages as well
This patch re-implements matching and reporting for test runner.
Among other improvements:
- test failures now show a short snippet from test
- test failures now explicitly say what received and what was expected
- `expect.toBe()` now does text diff when gets strings as input
- `expect.toEqual` now does object diff
The plan is to collect logs for the whole test run and upload it later on
using https://github.com/actions/upload-artifact
Produced log size:
- 163MB (8.5MB zipped) for Chromium: `DEBUG=* npm run unit 2>log`
- 135MB (4.8MB zipped) for WebKit: `DEBUG=*,-pw:wrapped* npm run wunit 2>log`
- 29MB (4.0MB zipped) for Firefox: `DEBUG=* npm run funit 2>log`
This introduces a handful of new markdown preprocessor commands to
insert browser versions:
- `GEN:chromium-version-if-release` - inserts current Chromium version
if we're doing release; noop otherwise.
- `GEN:firefox-version-if-release` - inserts current Firefox version
if we're doing release; noop otherwise.
And to generate badge links:
- `GEN:chromium-version-badge-if-release` - inserts current Chromium version
badge if we're doing release; noop otherwise.
- `GEN:firefox-version-badge-if-release` - inserts current Firefox version
badge if we're doing release; noop otherwise.
This doesn't touch webkit at all - we're yet to figure what to do with
webkit version.
NOTE: versions will be updated only once we release. This way our
README.md always represents last released version.
I enabled vscode autocomplete in our test files. Typechecking had too many errors to enable, but it caught some real bugs that I will fix in a follow up.
This patch contains:
* `test/types.d.ts` - d.ts file for our test runner.
* `test/tsconfig.json` - typescript project for our tests.
* JSDoc header in all specs to mark the describe as a TestSuite
* Drive-by fix of a launcher test that was using `if` instead of `it`
* Some drive-by fixes of unimpactful typos in tests.
This is mostly copied from Puppeteer's troubleshooting.md, with everything under a Chromium header and a few tweaks to make things make sense for Playwright.
We can add other browsers to this document once we figure out how to troubleshoot them.
Fixes#583
## playwright-chromium
- installs chromium
- exposes chromium api from playwright-core
## playwright-firefox
- installs firefox
- exposes firefox api from playwright-core
## playwright-webkit
- installs webkit
- exposes webkit api from playwright-core
## playwright-core
- downloads no browsers
- contains all of the js code
- designed for internal use
## playwright
- downloads all browsers
- exposes the entire api from playwright-core
## github
- downloads all browsers, generates protocol definitions, builds typescript
- exposes "playwright-core" api
This patch adds a basic source map support to test runner.
SourceMap support is powered by Chromium DevTools source map
implementation (thus copyright). Unlike popular `source-map` npm
module, it's sync and pretty straight-forward.
The `SourceMap.js` file has a few modifications wrt upstream
Chromium version:
- reverse mappings API is removed. There's no need to ever compute them
- the `upperBoundary` function from DevTools' platform is inlined
`protocol.d.ts` had to move to `protocol.ts` otherwise typescript refuses to include it in the out directory.
Removed the old d.ts generator. It will need to be rewritten anyway.
These new types include private stuff that they probably shouldn't, and are missing documentation. I'll follow up with a better d.ts generator later.
#6
