Contribution Guideline

Starknet Foundry is under active development and is open for contributions!

Opening an issue

If you think something doesn't work or something is missing please open an issue! This way we can address this problem and make Starknet Foundry better! Before opening an issue, it is always a good idea to search existing issues and verify if a similar one doesn't already exist.

Contributing

Environment setup

See development guide in Starknet Foundry book for environment setup.

Selecting an issue

If you are a first time contributor pick up any issue labeled as good-first-issue. Write a comment that you would like to work on it and we will assign it to you. Need some guidance? Reach out to other developers on Telegram.

If you are a more experienced Starknet Foundry contributor you can pick any issue labeled as help-wanted. Make sure to discuss the details with the core team beforehand.

Writing Tests

Please make sure the feature you are implementing is thoroughly tested with automatic tests. You can check existing tests in the repository to see the recommended approach to testing.

Flaky tests

Some tests fail intermittently due to dependence on an external service, network issues, etc.

If no clear fix is possible or trivial, to avoid blocking CI, configure targeted retries for known flaky tests in .config/nextest.toml. Choose retry count, backoff and other options based on context:

• observed fail rate
• external dependency reliability
• expected recovery time

Snapshot tests

Some tests use insta snapshots files (.snap) to store expected test output, specifically for testing some of Starknet Foundry features with older Scarb versions. When adding such test case, please add a snap_ prefix to its name to ensure it's tested on CI for all supported Scarb versions. To make sure snapshot tests pass for all currently supported Scarb versions, run:

./scripts/check_snapshots.sh

If some of the snapshot tests fail, run:

./scripts/check_snapshots.sh --fix

and review the newly generated snapshots.

Pull Request Size

Try to make your pull request self-contained, only introducing the necessary changes. If your feature is complicated, consider splitting the changes into meaningful parts and introducing them as separate pull requests.

Creating very large pull requests may significantly increase review time or even prevent them from being merged.

Contributions Related to Spelling and Grammar

At this time, we will not be accepting contributions that only fix spelling or grammar errors in documentation, code or elsewhere.

sncast Guidelines

Command Outputs

Please follow these rules when creating outputs for sncast:

• Use an imperative tone
• Keep your message concise and to the point
• When displaying config, use key: value format
• If the executed command has a natural successor-command, display it as hint in the output. For example, the output of declare command should include a hint to use deploy command next.