Contribution Guidelines
Welcome, and thank you for your interest in contributing to this project!
There are many ways in which you can contribute, beyond writing code. The goal of this document is to provide a high-level overview of how you can get involved.
Have a question? Feel free to ask it on GitHub Discussions board.
Your comments and feedback are welcome. You can leave your feedback on GitHub Discussions or you can leave a rated review on one of the following webstores:
Have you identified a reproducible problem in the extension? Have a feature request? Here's how you can make reporting your issue as effective as possible.
Before you create a new issue, please do a search in open issues to see if the issue or feature request has already been filed.
If you find your issue already exists, make relevant comments and add your reaction. Use a reaction in place of a "+1" comment:
- 👍 - upvote
- 👎 - downvote
If you cannot find an existing issue that describes your bug or feature, create a new issue using the guidelines below.
File a single issue per problem and feature request. Do not enumerate multiple bugs or feature requests in the same issue.
Do not add your issue as a comment to an existing issue unless they are the same ones. Many issues look similar, but have different causes.
The more information you can provide, the more likely someone will be successful at reproducing the issue and finding a solution.
For your convenience, we've added issue templates to make easier for you to follow these guidelines. These are available in the new issue section.
Please remember to do the following:
- Search the issue repository to ensure your report is a new issue
- Separate issues reports
- Include as much information as you can to your report
Don't feel bad if the developers can't reproduce the issue right away. They will simply ask for more information!
Once your report is submitted, be sure to stay in touch with the devs in case they need more help from you.
Important
Whenever you want to contribute to the codebase, you should do it only after you got assigned on an issue
If you are interested in writing code to fix issues or implement new awesome features you can follow this guidelines to get a better result.
Check out the issues section for a list of all potential areas for contributions.
To improve the chances to get a pull request merged you should select an issue that is labeled with the help-wanted label. If the issue you want to work on is not labeled with help-wanted, you can start a conversation with the project maintainers asking whether an external contribution will be considered.
Important
Just because an issue exists in the repository does not mean we will accept a contribution.
To avoid multiple pull requests resolving the same issue, make sure that you are assigned on the issue.
Warning
Avoid working on an issue that is not assigned to you (especially, when it is assigned to someone else!) We may reject these PRs!
Note
If you use Dev Containers or GitHub Codespaces, you can skip this section
- Node.js 20
- VS Code (optional, but strongly recommended)
Tip
It is strongly recommended to use VS Code editor during development, since this repository comes with pre-defined rules, extensions and other features for the VS Code that will significantly simplify development process.
Once you have cloned the repository you can execute following commands:
Tip
If you use VS Code, you can use pre-defined tasks to run most of required actions (F1 -> Tasks: Run Task)
# Debug
npm run dev
# Lint
npm run lint
# Build
npm run build
# Pack
npm run zipNote
For build and zip tasks npm run lint executes automatically.
By default, all actions are done for Chrome browser. If you want to use another browser (e.g. Firefox), add -b option to the command:
npm run dev -- -b edge
npm run zip -- -b firefoxCaution
npm run dev -- -b firefox uses MV2 which is incompatible with some of used APIs (e.g. browser.action). When testing on Firefox it is recommended to build and sideload the extension, instead of running it in dev mode.
Important
Before debugging, you may need to set your browser binaries location, or otherwise configure debugging environment. Please refer to web-ext.config.ts of the WXT framework for more details.
Before submitting your PR, make sure you have tested the final extension via sideloading.
You can find sideloading instructions in the project's README.
Important
Before submitting your PR, make sure you've tested the extension on both Firefox and at least one Chromium-based browser, since these browser have only partially compatible APIs. It is recommended to test the extension only on target browsers.
Please refer to the Code style guidelines to learn more about code formatting rules for this project.
If you want to help us to translate this extension into other languages, please follow these steps:
- Go to
localesfolder. - Choose a locale file that you will use as a base for your translation.
-
Duplicate selected file and rename it with appropriate language code (e.g. if you were to add a French locale, the file and its path path would be:
locales/fr.yml). - Open the file in text editor and familiarize yourself with it's structure.
- Translate text in file. Make sure that you translate only necessary text (use other locale files as a reference on what you should translate). Do not translate anything else.
- Build and test the extension to review your locale. This step is optional, but it will help you to catch all discrepancies and typos.
- Commit the changes and open a PR.
Tip
Try adapting text instead of just translating word-to-word. Some sentences don't make sense in one language, but do in others.
Pull requests that fix typos are welcomed but please make sure it doesn't touch multiple feature areas, otherwise it will be difficult to review. Pull requests only fixing spell check errors in source code (not visible in UI) are not recommended.
Important
Whenever you want to contribute to the codebase, you should do it only after you got assigned on an issue
To enable us to quickly review and accept your pull requests, always create one pull request per issue and link the issue in the pull request. Never merge multiple requests in one unless they have the same root cause. Be sure to follow our Coding Guidelines and keep code changes as small as possible. Avoid pure formatting changes to code that has not been modified otherwise. Fill pull request content according to its template. Deviations from the template are not recommended.
This section will give you an overview of the development process. Use this steps to understand what you need to expect and do.
- New issue is created
- Contributor is assigned to the issue
- A fork or a dedicated branch is created for the issue
- Changes to the codebase are made
- PR into
nextbranch is opened - PR passes reviews and CI checks
- PR is merged into
next - After some time
nextis merged intomain - New release is created
- The cycle repeats
Your contributions to open source, large or small, make great projects like this possible. Thank you for taking the time to contribute.
These Contribution Guidelines are adapted from the Contributing to VS Code
©2025 Eugene Fox. Licensed under MIT license