Welcome to the Optimism Monorepo Contributing Guide! If you're reading this then you might be interested in contributing to the Optimism Monorepo. Before diving into the specifics of this repository, you might be interested in taking a quick look at just a few of the ways that you can contribute. You can:
- Report issues in this repository. Great bug reports are detailed and give clear instructions for how a developer can reproduce the problem. Write good bug reports and developers will love you.
- IMPORTANT: If you believe your report impacts the security of this repository, refer to the canonical Security Policy document.
- Fix issues that are tagged as
D-good-first-issue
orS-confirmed
. - Larger projects are listed on this project board. Please talk to us if you're considering working on one of these, they may not be fully specified so it will reduce risk to discuss the approach and ensure that it's still relevant.
- Help improve the Optimism Developer Docs by reporting issues, fixing typos, or adding missing sections.
- Get involved in the protocol design process by joining discussions within the OP Stack Specs repository.
Interactions within this repository are subject to a Code of Conduct adapted from the Contributor Covenant.
Dependency | Version | Version Check Command |
---|---|---|
git | ^2 |
git --version |
go | ^1.21 |
go version |
node | ^20 |
node --version |
nvm | ^0.39 |
nvm --version |
just | ^1.34.0 |
just --version |
foundry | ^0.2.0 |
forge --version |
make | ^3 |
make --version |
jq | ^1.6 |
jq --version |
direnv | ^2 |
direnv --version |
docker | ^24 |
docker --version |
docker compose | ^2.23 |
docker compose version |
Make sure to use the version of node
specified within .nvmrc
.
You can use nvm
to manage multiple versions of Node.js on your machine and automatically switch to the correct version when you enter this repository.
foundry
is updated frequently and occasionally contains breaking changes.
This repository pins a specific version of foundry
inside of versions.json
.
Use the command just update-foundry
at the root of the monorepo to make sure that your version of foundry
is the same as the one currently being used in CI.
direnv
is a tool used to load environment variables from .envrc
into your shell so you don't have to manually export variables every time you want to use them.
direnv
only has access to files that you explicitly allow it to see.
After installing direnv
, you will need to make sure that direnv
is hooked into your shell.
Make sure you've followed the guide on the direnv
website, then close your terminal and reopen it so that the changes take effect (or source
your config file if you know how to do that).
Docker Desktop should come with docker compose
installed by default.
You'll have to install the compose
plugin if you're not using Docker Desktop or you're on linux.
Clone the repository and open it:
git clone [email protected]:ethereum-optimism/optimism.git
cd optimism
Make sure that you've installed all of the required Software Dependencies before you continue. You will need foundry to build the smart contracts found within this repository. Refer to the note on foundry as a dependency for instructions.
Install dependencies and build all packages within the monorepo by running:
make build
Packages built on one branch may not be compatible with packages on a different branch. You should rebuild the monorepo whenever you move from one branch to another. Use the above command to rebuild the monorepo.
Before running tests: follow the above instructions to get everything built.
cd packages/contracts-bedrock
just test
Change directory to the package you want to run tests for, then:
go test ./...
See this document
We perform static analysis with slither
.
You must have Python 3.x installed to run slither
.
To run slither
locally, do:
cd packages/contracts-bedrock
pip3 install slither-analyzer
just slither
Labels are divided into categories with their descriptions annotated as <Category Name>: <description>
.
The following are a comprehensive list of label categories.
- Area labels (
A-
): Denote the general area for the related issue or PR changes. - Category labels (
C-
): Contextualize the type of issue or change. - Meta labels (
M-
): These add context to the issues or prs themselves primarily relating to process. - Difficulty labels (
D-
): Describe the associated implementation's difficulty level. - Status labels (
S-
): Specify the status of an issue or pr.
Labels also provide a versatile filter for finding tickets that need help or are open for assignment. This makes them a great tool for contributors!
To find tickets available for external contribution, take a look at the
M-community
You can filter by the
D-good-first-issue
Also, all labels can be seen by visiting the labels page
When altering label names or deleting labels there are a few things you must be aware of.
- If the
S-stale
Status: Will be closed unless there is activity label is altered, the close-stale workflow should be updated. - If the
M-dependabot
Meta: dependabot opened pr label is altered, the dependabot config file should be adjusted. - Saved label filters for project boards will not automatically update. These should be updated if label names change.
🚨 Before making any non-trivial change, please first open an issue describing the change to solicit feedback and guidance. This will increase the likelihood of the PR getting merged.
In general, the smaller the diff the easier it will be for us to review quickly.
In order to contribute, fork the appropriate branch, for non-breaking changes to production that is develop
and for the next release that is normally release/X.X.X
branch, see details about our branching model.
Additionally, if you are writing a new feature, please ensure you add appropriate test cases.
Follow the Development Quick Start to set up your local development environment.
We recommend using the Conventional Commits format on commit messages.
Unless your PR is ready for immediate review and merging, please mark it as 'draft' (or simply do not open a PR yet).
Once ready for review, make sure to include a thorough PR description to help reviewers. You can read more about the guidelines for opening PRs in the PR Guidelines file.
Bonus: Add comments to the diff under the "Files Changed" tab on the PR page to clarify any sections where you think we might have questions about the approach taken.
We aim to provide a meaningful response to all PRs and issues from external contributors within 2 business days.
We use the git rebase
command to keep our commit history tidy.
Rebasing is an easy way to make sure that each PR includes a series of clean commits with descriptive commit messages
See this tutorial for a detailed explanation of git rebase
and how you should use it to maintain a clean commit history.