Skip to content

Latest commit

 

History

History
137 lines (85 loc) · 4.72 KB

CONTRIBUTING.md

File metadata and controls

137 lines (85 loc) · 4.72 KB
Raw

Contributing

Thanks for your interest in contributing to zabi! Please take a moment to review this document before submitting a pull request.

If you want to contribute, but aren't sure where to start, you can create a new discussion.

Note

Please ask first before starting work on any significant new features.

It's never a fun experience to have your pull request declined after investing time and effort into a new feature. To avoid this from happening, we request that contributors create a feature request to first discuss any API changes or significant new ideas.


Basic guide

This guide is intended to help you get started with contributing. By following these steps, you will understand the development process and workflow.

  1. Cloning the repository
  2. Installing zig
  3. Installing Foundry
  4. Building Zabi
  5. Running the test suite
  6. Writing documentation
  7. Submitting a pull request

Cloning the repository

To start contributing to the project, clone it to your local machine using git:

git clone https://github.com/Raiden1411/zabi.git

Or the GitHub CLI:

gh repo clone Raiden1411/zabi

Installing Zig

You can install zig using any package manager from your distribution in case you are on linux. Otherwise you can download the binaries here.

You can also use zvm which is the recommended way of managing you zig version installs.

Installing Foundry

Zabi uses Foundry for testing. We run 3 local Anvil instance against a forked Ethereum node, where we can also use tools like Forge to deploy test contracts to it.

Install Foundry using the following command:

curl -L https://foundry.paradigm.xyz | bash

Building

Once you have cloned the repo and have the correct version of zig running on your computer you can now run zig build to ensure that everything gets built properly.

Zabi supports version 0.13.0 of zig in seperate branches. You can checkout each seperate branch and work in those branches if that is your goal.

Running the test suite

Before running the tests you will need to either remove the client tests if you dont't want to start the anvil instances or you will need to start 3 anvil instances for Mainnet ethereum, Mainnet Sepolia and Optimism Sepolia in order to run the tests successfully.

Then you can run zig build test -freference-trace to run our test suite to ensure that you don't have any issues when making changes.

When adding new features or fixing bugs, it's important to add test cases to cover the new/updated behavior.

Writing documentation

Documentation is crucial to helping developers of all experience levels use zabi. zabi uses Vocs and Markdown for the documentation site (located at docs). To start the site in dev mode, run:

pnpm dev

Zabi use mostly auto-generated documentation from its source code. If you make a change to the code make sure that to run zig build docs in order to update any changes. If you create a new file and want to add it to the website make to update docs/sidebar.ts to include it.

Submitting a pull request

When you're ready to submit a pull request, you can follow these naming conventions:

  • Pull request titles use the Imperative Mood (e.g., Add something, Fix something).

When you submit a pull request, GitHub will automatically lint, build, and test your changes. If you see an ❌, it's most likely a bug in your code. Please, inspect the logs through the GitHub UI to find the cause.

The CI might also fail sometimes when it comes to the test runner. If running doesn't fix the problem then it's most likely a bug in your code.


✅ Now you're ready to contribute to zabi!