Playwright **requires an issue** for every contribution, except for minor documentation updates. We strongly recommend
Sign in to like and favorite skills
Playwright requires an issue for every contribution, except for minor documentation updates. We strongly recommend to pick an issue labeled open-to-a-pull-request for your first contribution to the project.
If you are passionate about a bug/feature, but cannot find an issue describing it, file an issue first. This will facilitate the discussion, and you might get some early feedback from project maintainers before spending your time on creating a pull request.
Make sure you're running Node.js 20 or later.
node --version
Clone the repository. If you plan to send a pull request, it might be better to fork the repository first.
git clone https://github.com/microsoft/playwright cd playwright
Install dependencies and run the build in watch mode.
npm ci npm run watch npx playwright install
Playwright is a multi-package repository that uses npm workspaces. For browser APIs, look at
. For test runner, see packages/playwright-core
.packages/playwright
Note that some files are generated by the build, so the watch process might override your changes if done in the wrong file. For example, TypeScript types for the API are generated from the
.docs/src
Coding style is fully defined in eslint.config.mjs. Before creating a pull request, or at any moment during development, run linter to check all kinds of things:
npm run lint
Comments should have an explicit purpose and should improve readability rather than hinder it. If the code would not be understood without comments, consider re-writing the code to make it self-explanatory.
Every part of the public API should be documented in
, in the same change that adds/changes the API. We use markdown files with custom structure to specify the API. Take a look around for an example.docs/src
Various other files are generated from the API specification. If you are running
npm run watchLarger changes will require updates to the documentation guides as well. This will be made clear during the code review.
Playwright requires a test for almost any new or modified functionality. An exception would be a pure refactoring, but chances are you are doing more than that.
There are multiple test suites in Playwright that will be executed on the CI. The two most important that you need to run locally are:
Library tests cover APIs not related to the test runner.
# fast path runs all tests in Chromium npm run ctest # slow path runs all tests in three browsers npm run test
Test runner tests.
npm run ttest
Since Playwright tests are using Playwright under the hood, everything from our documentation applies, for example this guide on running and debugging tests.
Note that tests should be hermetic, and not depend on external services. Tests should work on all three platforms: macOS, Linux and Windows.
Commit messages should follow the Semantic Commit Messages format:
label(namespace): title description footer
fixfeatdocstestdevopschoreExample:
feat(trace viewer): network panel filtering This patch adds a filtering toolbar to the network panel. <link to a screenshot> Fixes #123, references #234.
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Make sure to keep your PR (diff) small and readable. If necessary, split your contribution into multiple PRs. Consult GitHub Help for more information on using pull requests.
After a successful code review, one of the maintainers will merge your pull request. Congratulations!
No new dependencies
There is a very high bar for new dependencies, including updating to a new version of an existing dependency. We recommend to explicitly discuss this in an issue and get a green light from a maintainer, before creating a pull request that updates dependencies.
Custom browser build
To run tests with custom browser executable, specify
CRPATHWKPATHFFPATHCRPATH=<path-to-executable> npm run ctest
You will also find
DEBUG=pw:browserBuilding documentation site
The playwright.dev documentation site lives in a separate repository, and documentation from
is frequently rolled there.docs/src
Most of the time this should not concern you. However, if you are doing something unusual in the docs, you can build locally and test how your changes will look in practice:
playwrightThis project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.