# Contributing

## Choose an issue

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 passioned 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 a change

Make sure you're running Node.js 20 or later.
```bash
node --version
```

Clone the repository. If you plan to send a pull request, it might be better to [fork the repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo) first.
```bash
git clone https://github.com/microsoft/playwright
cd playwright
```

Install dependencies and run the build in watch mode.
```bash
npm ci
npm run watch
npx playwright install
```

Playwright is a multi-package repository that uses npm workspaces. For browser APIs, look at [`packages/playwright-core`](https://github.com/microsoft/playwright/blob/main/packages/playwright-core). For test runner, see [`packages/playwright`](https://github.com/microsoft/playwright/blob/main/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`](https://github.com/microsoft/playwright/blob/main/docs/src).

Coding style is fully defined in [.eslintrc](https://github.com/microsoft/playwright/blob/main/.eslintrc.js). Before creating a pull request, or at any moment during development, run linter to check all kinds of things:
  ```bash
  npm run lint
  ```

Comments should be generally avoided. If the code would not be understood without comments, consider re-writing the code to make it self-explanatory.

### Write documentation

Every part of the public API should be documented in [`docs/src`](https://github.com/microsoft/playwright/blob/main/docs/src), 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.

Various other files are generated from the API specification. If you are running `npm run watch`, these will be re-generated automatically.

Larger changes will require updates to the documentation guides as well. This will be made clear during the code review.

## Add a test

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](https://github.com/microsoft/playwright/blob/main/tests) 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.
  ```bash
  # fast path runs all tests in Chromium
  npm run ctest

  # slow path runs all tests in three browsers
  npm run test
  ```

- Test runner tests.
  ```bash
  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](https://playwright.dev/docs/running-tests#running-tests).

Note that tests should be *hermetic*, and not depend on external services. Tests should work on all three platforms: macOS, Linux and Windows.

## Write a commit message

Commit messages should follow the [Semantic Commit Messages](https://www.conventionalcommits.org/en/v1.0.0/) format:

```
label(namespace): title

description

footer
```

1. *label* is one of the following:
    - `fix` - bug fixes
    - `feat` - new features
    - `docs` - documentation-only changes
    - `test` - test-only changes
    - `devops` - changes to the CI or build
    - `chore` - everything that doesn't fall under previous categories
1. *namespace* is put in parenthesis after label and is optional. Must be lowercase.
1. *title* is a brief summary of changes.
1. *description* is **optional**, new-line separated from title and is in present tense.
1. *footer* is **optional**, new-line separated from *description* and contains "fixes" / "references" attribution to github issues.

Example:

```
feat(trace viewer): network panel filtering

This patch adds a filtering toolbar to the network panel.
<link to a screenshot>

Fixes #123, references #234.
```

## Send a pull request

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more information on using pull requests.

After a successful code review, one of the maintainers will merge your pull request. Congratulations!

## More details

**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 `CRPATH`, `WKPATH` or `FFPATH` env variable that points to browser executable:
```bash
CRPATH=<path-to-executable> npm run ctest
```

You will also find `DEBUG=pw:browser` useful for debugging custom builds.

**Building documentation site**

The [playwright.dev](https://playwright.dev/) documentation site lives in a separate repository, and documentation from [`docs/src`](https://github.com/microsoft/playwright/blob/main/docs/src) is frequently rolled there.

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:
1. Clone the [microsoft/playwright.dev](https://github.com/microsoft/playwright.dev) repo.
1. Follow [the playwright.dev README instructions to "roll docs"](https://github.com/microsoft/playwright.dev/#roll-docs) against your local `playwright` repo with your changes in progress.
1. Follow [the playwright.dev README instructions to "run dev server"](https://github.com/microsoft/playwright.dev/#run-dev-server) to view your changes.

## Contributor License Agreement

This 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.

### Code of Conduct

This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.

## Coding Standards

To ensure consistency and maintainability of the codebase, please follow these coding standards:

1. Use camelCase for variable and function names.
2. Use PascalCase for class names.
3. Use 2 spaces for indentation.
4. Use single quotes for strings, except to avoid escaping.
5. Use semicolons at the end of statements.
6. Use trailing commas where possible.
7. Write clear and concise comments where necessary.
8. Keep functions and classes small and focused.
9. Write unit tests for new code and ensure existing tests pass.

## Pull Request Process

To submit a pull request, follow these steps:

1. Fork the repository and create a new branch for your contribution.
2. Make your changes and ensure that the tests and checks pass.
3. Write clear and concise commit messages.
4. Push your changes to your forked repository.
5. Submit a pull request to the main repository.
6. Ensure that your pull request passes all checks and reviews.
7. Address any feedback or requested changes from reviewers.
8. Once approved, your pull request will be merged by a maintainer.

## Issue Reporting

To report an issue, follow these guidelines:

1. Search the issue tracker to see if the issue has already been reported.
2. If the issue has not been reported, create a new issue with a clear and descriptive title.
3. Provide a detailed description of the issue, including steps to reproduce, expected behavior, and actual behavior.
4. Include any relevant logs, screenshots, or code snippets.
5. Label the issue appropriately (e.g., bug, enhancement, question).
6. Be responsive to any questions or requests for additional information from maintainers or other contributors.