Skip to content

Latest commit

 

History

History
103 lines (70 loc) · 4.2 KB

CONTRIBUTING.md

File metadata and controls

103 lines (70 loc) · 4.2 KB
Raw

How to contribute

We love pull requests. And following these guidelines will make your pull request easier to merge.

If you want to contribute but don’t know what to do, take a look at these two labels: help wanted and good first issue.

Use GitHub interface for simple documentation changes, otherwise follow the steps below.

Prerequisites

Development workflow

Start from the develop branch.

To build your changes, run:

npm run build

Run linters and tests:

npm test

Or run tests in watch mode:

npm test --watch

By default the tests are executed in your local Devnet. If you want to use a specific RPC node, you have to set some global variables before executing the tests:

export TEST_RPC_URL=http://192.168.1.44:9545/rpc/v0.5 # example of a Pathfinder node located in your local network
export TEST_RPC_URL=https://starknet-testnet.public.blastapi.io/rpc/v0.5 # example of a public testnet node
export TEST_ACCOUNT_ADDRESS=0x065A822f0000000000000000000000000c26641
export TEST_ACCOUNT_PRIVATE_KEY=0x02a80000000000000000000000001754438a

The global variables above will only be valid for some of the tests. The recommended and more straightforward approach is to go with the docker. You just need to do the following steps:

  • Install Docker (it can also be installed via a package manager, e.g. brew for Mac)
  • Run Docker on your machine (open the application).
  • Go to the starknet-devnet-rs and copy the docker pull command from the latest tag
  • Run docker pull shardlabs/starknet-devnet-rs:latest in your terminal
  • Run tests locally with npm run test

Don’t forget to add tests and update documentation for your changes. Documentation can be archived by using JSDoc.

Please update the npm lock file (package-lock.json) if you add or update dependencies.

Commit messages

For commit messages use Conventional Commits, like so: feat(scope): topic

Note that the feat and fix commit messages are used for compiling the changelog. They should be relative to the current state of the target branch they should be merged into and not the feature branch where they are initially committed.

Example of incorrect commit messages:

fix: repair some bug
fix: rectify failing test
fix: adjust formatting
fix: add comments
fix: repair some other bug

Example of correct commit messages:

fix: repair some bug
test: rectify failing test
chore: adjust formatting
chore: add comments
fix: repair some other bug

Pull request targets

For the most common pull requests such as bug fixes, feature additions, documentation changes, etc., target the develop branch.

For major changes that markedly transform the existing API or significantly alter the behavior of some functionality ensure that the corresponding commits contain appropriate Conventional Commits breaking change notations and as the pull request target select the beta branch.

Other notes

  • If you have commit access to the repository and want to make a big change or are unsure about something, make a new branch and open a pull request.
  • We’re using Prettier to format code, so don’t worry much about code formatting.
  • Don’t commit generated files, like minified JavaScript.
  • Don’t change the version number or changelog.

Need help?

If you want to contribute but have any questions, concerns or doubts, feel free to ping maintainers. Ideally create a pull request with WIP (Work in progress) in its title and ask questions in the pull request description.