Skip to content

Latest commit

 

History

History
179 lines (111 loc) · 8.03 KB

CONTRIBUTING.md

File metadata and controls

179 lines (111 loc) · 8.03 KB
Raw

RainbowKit Contribution Guide

Thanks for your interest in contributing to RainbowKit! 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.

Pull requests

Please ask first before starting work on any significant new features. This includes things like adding new wallets, chains, components, etc.

It's never a fun experience to have your pull request declined after investing a lot of 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.

Prerequisites

This project uses pnpm as a package manager. The required pnpm version to get started is 9.1.0.

Development environment

To play around with code while making changes, you can run the local development environment:

pnpm install
pnpm dev

This will run an example app on localhost:3000 and the documentation site on localhost:3001.

The example app code is located in packages/example. The documentation site code is located in site. Make sure you clean up after yourself before pushing up any changes.

All API changes should also include updates to README.md and the documentation site. Documentation is crucial to helping developers of all experience levels use RainbowKit.

Coding standards

Our code formatting rules are defined in biome.json. You can check your code against these standards by running:

pnpm lint

To automatically fix any errors in your code, you can run:

pnpm lint:fix

Running tests

RainbowKit has a suite of unit tests that can be run with the following command:

pnpm test

If snapshot tests fail, you can run the following command to update the snapshots:

pnpm test:update

Working on create-rainbowkit

Template

To run the Next.js app template directly without any scaffolding:

pnpm dev:template:next-app

If you make any template changes, please be sure to commit the result of running the CLI test script. This keeps the lock file is up to date since the scaffolded test app is part of the monorepo.

pnpm test:cli:dev

CLI

To build the CLI in watch mode:

pnpm dev:cli

To scaffold a template with the CLI and start a local dev server:

pnpm test:cli:dev

Linking CLI globally

You can also link the create-rainbowkit command globally. This allows you to try out create-rainbowkit elsewhere on your machine. Note that it will install the latest version of RainbowKit from npm so it's possible the template will be using APIs that haven't been released yet. This is most useful for seeing what the CLI looks like for a typical consumer.

pnpm link:cli

Release notes

RainbowKit uses Changesets to manage versioning and publishing.

Each PR with a user-facing change (API change, bug fix, notable UI update, etc.) should include a “changeset”, which is a markdown file in the .changeset directory. This directory acts as a release queue and is automatically cleared out after each release.

Each changeset defines which package(s) should be published and whether the change should be a major/minor/patch release, as well as providing release notes that will be added to the changelog upon release.

To create a new changeset, run pnpm changeset. This will run the Changesets CLI, prompting you for details about the change. You’ll be able to edit the file after it’s created — don’t worry about getting everything perfect up front.

Since we’re currently in beta, all changes should be marked as a minor/patch release to keep us within the v0.x range.

Even though you can technically use any markdown formatting you like, headings should be avoided since each changeset will ultimately be nested within a bullet list. Instead, bold text should be used as section headings.

If your PR is making changes to an area that already has a changeset (e.g. there’s an existing changeset covering theme API changes but you’re making further changes to the same API), you should update the existing changeset in your PR rather than creating a new one.

The first time a PR with a changeset is merged after a release, a new PR will automatically be created called chore: version packages. Any subsequent PRs with changesets will automatically update this existing version packages PR. Merging this PR is the first step of the release process.

Releasing to npm

This section is only relevant for library maintainers who are releasing new versions of the library.

When you’re ready to publish, the chore: version packages PR should be reviewed to double check that the version number(s) are correct and that the release notes are correct. Since we’re currently in beta, version numbers should remain within the v0.x range.

Once you’ve merged the version packages PR, you’ll need to run the release step locally. First ensure you’re in the main branch with the latest changes.

git checkout main
git pull

Next, run the release:test script. This will clean the repo and reinstall dependencies, run the automated tests, build packages in release mode and start a local dev server on http://localhost:3000 so you can perform a quick manual smoke test.

pnpm release:test

If everything’s looking good, you can now run the release script. Note that the automated prerelease script will verify that you’re in the correct branch with no uncommitted changes before testing and rebuilding everything.

pnpm release

Assuming everything went well, the release script will create a new git tag for the latest version, so be sure to push it to GitHub.

git push --tags

Once you’ve pushed the tag, you can create a new release on GitHub.

If you published rainbowkit:

If you published rainbowkit-siwe-next-auth:

If you published create-rainbowkit:

If you published rainbow-button:

If at any stage you’re unsure of the formatting, you can reference past RainbowKit releases.

That’s it — you’re all done! 🎉