Thank you for considering contributing to the NOS3! Please read these guidelines before submitting a pull request or opening an issue.
Note
This code guideline must be followed for both contributors and maintainers to review the PRs.
We strive to maintain clean, readable, and maintainable code. Please follow these guidelines when contributing to the project:
- Follow the Effective Go guidelines.
- Follow the Go Doc Comments guidelines.
- Follow the principles of clean code as outlined in Robert C. Martin's "Clean Code" book.
- Write tests/benchmarks for new code or changes to existing code, and make sure all tests pass before submitting a pull request.
There are some makefile targets that you can use when developing this codebase:
devtools: will install all devtools you need in the development process.unit-test,test,test-race: runs all existing tests.fmt: formats the code using gofumpt. (Run beforechecktarget always.)check: runs golangci-lint linter based on its config.build: build an nos3 binary on thebuild/nos3path.pre-commit: executes formatter, linter, and tests.compose-up: spins up the development docker compose, which runs all required third-party development services.compose-down: stops the development docker compose stuff.
Error and log messages should not start with a capital letter (unless it's a proper noun or acronym).
- Correct ✅: "unable to connect to client"
- Incorrect ❌: "Unable to connect to client"
All changes to the core must contain proper and well-defined unit tests, also previous tests must be passed as well.
This codebase uses testify for unit tests, make sure you follow this guide for tests:
- For panic cases, make sure you use
assert.Panics - For checking err using
assert.ErrorIsmake sure you pass the expected error as the second argument. - For checking equality using
assert.Equal, make sure you pass the expected value as the first argument.
Make sure you follow this guide when you write or change benchmarks to reach an accurate result.
Follow these rules for help messages for CLI commands and flags:
- Help string should not start with a capital letter.
- Don't include the default value in the help string.
- Include the acceptable range for the flags that accept a range of values.
Please follow these rules when committing changes to the NOS3:
- Each commit should represent a single, atomic change to the codebase. Avoid making multiple unrelated changes in a single commit.
- Use the Conventional Commits format for commit messages and Pull Request titles.
List of conventional commit types:
| Types | Description |
|---|---|
| fix | A bug fix |
| feat | A new feature |
| docs | Documentation only changes |
| test | Adding missing tests or correcting existing tests |
| build | Changes that affect the build system or external dependencies |
| ci | Changes to our CI configuration files and scripts |
| perf | A code change that improves performance |
| refactor | A code change that neither fixes a bug nor adds a feature |
| style | Changes that do not affect the meaning of the code (white-space, formatting, etc) |
| chore | Other changes that don't modify src or test files |
The scope helps specify which part of the code is affected by your commit. It must be included in the commit message to provide clarity. Multiple scopes can be used if the changes impact several areas.
- Keep the commit message under 50 characters.
- Start the commit message with a lowercase letter and do not end with punctuation.
- Write commit messages in the imperative: "fix bug", not "fixed bug" or "fixes bug".
- Correct ✅: "feat(ws): close stale connections."
- Correct ✅: "feat(ws, config): max_wss connection limit"
- Incorrect ❌: "feat(config): Blacklist npubs"
- Incorrect ❌: "feat(config): blacklisted npubs"
Thank you for your contributions to the NOS3!