Skip to main content

​
Pull Request Workflow

​
Before Creating a PR

Ensure your code meets all quality standards: 
# Run linter
yarn lint

# Run tests
yarn test
Both commands must pass without errors before submitting a pull request.

​
Creating a Pull Request

  1. Create a feature branch with the naming convention <initials>-<feature>:
git checkout -b jd-add-staking-feature
  1. Make your changes following the code style guidelines
  2. Commit your changes with clear, descriptive messages: 
git add .
git commit -m "Add staking feature with delegation support"
  1. Push to your branch:
git push origin jd-add-staking-feature
  1. Open a pull request on GitHub with:
    • Clear title describing the change
    • Detailed description of what was changed and why
    • Reference to any related issues
    • Screenshots or demos if UI changes are involved

​
Pull Request Template

Use this template for your PR description: 
## Description
Brief summary of the changes and their purpose.

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
- [ ] Refactoring
- [ ] Performance improvement

## Changes Made
- List specific changes
- Include technical details
- Mention affected packages

## Testing
- [ ] Tested in Chrome
- [ ] Tested in Firefox
- [ ] Tested in Brave
- [ ] Unit tests added/updated
- [ ] Manual testing completed

## Related Issues
Closes #123
Related to #456

## Screenshots
(If applicable)

## Checklist
- [ ] Code passes `yarn lint`
- [ ] Code passes `yarn test`
- [ ] Copyright headers added to new files
- [ ] Documentation updated (if needed)
- [ ] Changelog updated (for stable releases)

​
Review Process

​
Reviewing Pull Requests

When reviewing a pull request, the goal is to suggest useful changes to the author. Reviews should finish with approval unless issues would result in:
Blocking Issues:
  • Buggy behavior
  • Undue maintenance burden
  • Breaking house coding style
  • Pessimization (reduction of speed as measured in benchmarks)
  • Feature reduction (removes functionality users rely on)
  • Uselessness (doesn’t add a feature or fix a known issue)

​
What Should NOT Block a PR

Reviews may not be used as an effective veto for a PR because:
  • There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix
  • It doesn’t fit well with some contributors’ longer-term vision for the project

​
Approval and Merge Criteria

Requirements before merging:
  • CI has finished successfully
  • At least one non-author contributor has reviewed the PR
  • All review comments have been addressed
  • No force pushes or Git history modifications

​
Fast-Track Merging

A pull request with no large change to logic that is an urgent fix may be merged after a non-author contributor has reviewed it well.

​
Standard Merging

No PR should be merged until:
  • All reviews’ comments are addressed
  • CI passes successfully
  • Appropriate approvals are received

​
Git Best Practices

​
Commit Messages

Write clear, descriptive commit messages: 
# Good
git commit -m "Add price subscription handler for real-time updates"
git commit -m "Fix memory leak in background service cleanup"
git commit -m "Refactor message passing to use typed interfaces"

# Avoid
git commit -m "fix"
git commit -m "updates"
git commit -m "wip"

​
No Force Pushes

Never use --force pushes or modify the Git history in any way. If you need to rebase, ensure you do it in your own repository before pushing.
# Never do this on shared branches
git push --force origin feature-branch

# If you must rebase, do it locally first
git fetch origin
git rebase origin/master
git push origin feature-branch  # Only if it's your branch

​
Branch Management

Keep your feature branch up to date with master: 
# Update your local master
git checkout master
git pull origin master

# Rebase your feature branch
git checkout jd-feature-branch
git rebase master

# Resolve any conflicts, then push
git push origin jd-feature-branch

​
Versioning

SubWallet Extension uses semantic versioning with two release tracks:

​
Development Versions

Development versions are automatically generated by GitHub Actions:
  • Format: x.y.z-nn (e.g., 1.2.3-45)
  • Generated on each commit to master
  • Used for testing and internal builds
  • No manual intervention required

​
Stable Versions

Stable versions require manual updates:
  1. Update version in the main package.json:
{
  "name": "@subwallet/extension",
  "version": "1.2.3",
  // ...
}
Change from x.y.z-nn to x.y.z (remove the -nn suffix).
  1. Update CHANGELOG.md with all changes since the last stable release:
## [1.2.3] - 2024-01-15

### Added
- New staking feature with delegation support
- Price subscription for real-time updates

### Fixed
- Memory leak in background service cleanup
- Balance display rounding issues

### Changed
- Refactored message passing to use typed interfaces
- Updated dependencies to latest versions

### Removed
- Deprecated API endpoints
  1. Commit the version changes:
git add package.json CHANGELOG.md
git commit -m "Bump version to 1.2.3"
  1. GitHub Actions will automatically generate version files for each package

​
Semantic Versioning Guidelines

Follow Semantic Versioning 2.0.0:
  • MAJOR (x.0.0): Incompatible API changes
  • MINOR (0.x.0): Add functionality in a backward-compatible manner
  • PATCH (0.0.x): Backward-compatible bug fixes
# Bug fix
1.2.3 -> 1.2.4

# New feature
1.2.3 -> 1.3.0

# Breaking change
1.2.3 -> 2.0.0

​
Changelog Updates

​
Format

The CHANGELOG.md follows the Keep a Changelog format: 
# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added
- Feature in development

## [1.2.3] - 2024-01-15

### Added
- New features

### Fixed
- Bug fixes

### Changed
- Changes in existing functionality

### Deprecated
- Soon-to-be removed features

### Removed
- Removed features

### Security
- Security fixes

​
When to Update

Update CHANGELOG.md when preparing a stable release. Development versions do not require changelog updates.
Include in changelog:
  • New features
  • Bug fixes
  • Breaking changes
  • Deprecations
  • Security updates
  • Important refactorings
Exclude from changelog:
  • Internal refactorings that don’t affect users
  • Documentation updates (unless significant)
  • Development dependency updates
  • Minor code style changes

​
CI/CD Pipeline

​
Continuous Integration

GitHub Actions automatically runs on every pull request:
  1. Lint Check: Runs yarn lint
  2. Type Check: Validates TypeScript types
  3. Tests: Runs yarn test
  4. Build: Compiles the extension

​
Pre-Merge Requirements

A pull request must not be merged until CI has finished successfully.
All checks must pass:
  • ✅ Lint check
  • ✅ Type check
  • ✅ Tests
  • ✅ Build
If any check fails, fix the issues and push new commits. The CI will run automatically.

​
Release Process

Declaring formal releases remains the prerogative of the project maintainers.

​
Release Checklist

For maintainers preparing a stable release:
  1. Ensure all PRs are merged
    • All planned features are complete
    • All bug fixes are included
    • CI is green on master
  2. Update version and changelog
    • Bump version in package.json
    • Update CHANGELOG.md with all changes
    • Commit changes: git commit -m "Bump version to x.y.z"
  3. Create a tag 
    git tag -a v1.2.3 -m "Release version 1.2.3"
git push origin v1.2.3
  4. GitHub Actions will
    • Generate version files for all packages
    • Build the extension
    • Create a GitHub release
    • Upload build artifacts
  5. Post-release
    • Update documentation if needed
    • Announce the release
    • Monitor for critical issues

​
Common Issues

​
PR Conflicts

If your PR has conflicts with master: 
git checkout master
git pull origin master
git checkout your-feature-branch
git rebase master
# Resolve conflicts in your editor
git add .
git rebase --continue
git push origin your-feature-branch

​
Failed CI Checks

Lint failures: 
yarn lint
# Fix issues manually or use auto-fix
yarn lint --fix
Test failures: 
yarn test
# Review failed tests and fix the code
Build failures: 
yarn build
# Review error messages and fix TypeScript errors

​
Getting Help

If you need help with the pull request process:
  1. Check existing PRs for examples
  2. Review the contribution guidelines
  3. Ask questions in the PR comments
  4. Reach out to maintainers for guidance
Don’t hesitate to ask for help! The community is here to support you in making quality contributions.

Build docs developers (and LLMs) love

Get started for freeTalk to us