|
| 1 | +# Contributing to OpenScan |
| 2 | + |
| 3 | +Thank you for your interest in contributing to OpenScan! This guide will help you get started. |
| 4 | + |
| 5 | +## Getting Started |
| 6 | + |
| 7 | +### Prerequisites |
| 8 | + |
| 9 | +- Node.js v22 |
| 10 | +- npm |
| 11 | + |
| 12 | +### Setup |
| 13 | + |
| 14 | +1. Fork the repository on GitHub |
| 15 | +2. Clone your fork: |
| 16 | + ```bash |
| 17 | + git clone https://github.com/YOUR_USERNAME/openscan.git |
| 18 | + cd openscan |
| 19 | + ``` |
| 20 | +3. Install dependencies: |
| 21 | + ```bash |
| 22 | + npm install |
| 23 | + ``` |
| 24 | +4. Start the development server: |
| 25 | + ```bash |
| 26 | + npm start |
| 27 | + ``` |
| 28 | + The app will be available at http://localhost:3030 |
| 29 | + |
| 30 | +## Development Workflow |
| 31 | + |
| 32 | +### Branch Naming |
| 33 | + |
| 34 | +Create feature branches from `dev` using descriptive names: |
| 35 | + |
| 36 | +- `feature/add-new-network` - New features |
| 37 | +- `fix/transaction-display` - Bug fixes |
| 38 | +- `docs/update-readme` - Documentation changes |
| 39 | +- `refactor/data-service` - Code refactoring |
| 40 | + |
| 41 | +### Creating a Branch |
| 42 | + |
| 43 | +```bash |
| 44 | +git checkout dev |
| 45 | +git pull origin dev |
| 46 | +git checkout -b feature/your-feature-name |
| 47 | +``` |
| 48 | + |
| 49 | +## Code Quality Checklist |
| 50 | + |
| 51 | +Before submitting a pull request, you must run these commands and ensure they pass: |
| 52 | + |
| 53 | +```bash |
| 54 | +# Fix formatting issues |
| 55 | +npm run format:fix |
| 56 | + |
| 57 | +# Fix linting issues |
| 58 | +npm run lint:fix |
| 59 | + |
| 60 | +# Verify type safety |
| 61 | +npm run typecheck |
| 62 | + |
| 63 | +# Run tests |
| 64 | +npm run test:run |
| 65 | +``` |
| 66 | + |
| 67 | +All code must: |
| 68 | + |
| 69 | +- Pass Biome formatting and linting checks |
| 70 | +- Pass TypeScript type checking with zero errors |
| 71 | +- Follow the 100-character line width limit |
| 72 | +- Use 2-space indentation consistently |
| 73 | + |
| 74 | +## Commit Guidelines |
| 75 | + |
| 76 | +We follow [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/). |
| 77 | + |
| 78 | +### Commit Message Format |
| 79 | + |
| 80 | +``` |
| 81 | +<type>: <description> |
| 82 | +
|
| 83 | +[optional body] |
| 84 | +
|
| 85 | +[optional footer(s)] |
| 86 | +``` |
| 87 | + |
| 88 | +### Types |
| 89 | + |
| 90 | +- `feat`: A new feature |
| 91 | +- `fix`: A bug fix |
| 92 | +- `docs`: Documentation changes |
| 93 | +- `style`: Code style changes (formatting, no logic change) |
| 94 | +- `refactor`: Code refactoring (no feature or bug fix) |
| 95 | +- `test`: Adding or updating tests |
| 96 | +- `chore`: Maintenance tasks |
| 97 | + |
| 98 | +### Examples |
| 99 | + |
| 100 | +``` |
| 101 | +feat: add support for Polygon zkEVM network |
| 102 | +fix: correct gas estimation for L2 transactions |
| 103 | +docs: update network configuration instructions |
| 104 | +refactor: extract common adapter logic to base class |
| 105 | +``` |
| 106 | + |
| 107 | +## Pull Request Process |
| 108 | + |
| 109 | +1. **Target Branch**: All PRs should target the `dev` branch |
| 110 | +2. **Title**: Use a clear, descriptive title following commit conventions |
| 111 | +3. **Description**: Explain what changed and why |
| 112 | +4. **Link Issues**: Reference any related issues (e.g., "Closes #123") |
| 113 | +5. **CI Checks**: Ensure all CI checks pass before requesting review |
| 114 | + |
| 115 | +When you open a PR, a template will be provided automatically. Please fill it out completely. |
| 116 | + |
| 117 | +## Architecture Overview |
| 118 | + |
| 119 | +OpenScan follows a layered architecture. For detailed information, see [CLAUDE.md](./CLAUDE.md). |
| 120 | + |
| 121 | +### Key Pattern: Fetcher → Adapter → Service |
| 122 | + |
| 123 | +1. **Fetcher Layer**: Makes raw RPC calls to blockchain nodes |
| 124 | +2. **Adapter Layer**: Transforms RPC responses into typed domain objects |
| 125 | +3. **Service Layer**: Orchestrates data fetching with caching |
| 126 | + |
| 127 | +When modifying data fetching: |
| 128 | + |
| 129 | +- Maintain the adapter pattern |
| 130 | +- Test both `fallback` and `parallel` RPC strategies |
| 131 | +- Update TypeScript types in `src/types/index.ts` if adding new fields |
| 132 | + |
| 133 | +## Adding a New Network |
| 134 | + |
| 135 | +1. Add chain ID to `src/types/index.ts` if creating new domain types |
| 136 | +2. Add default RPC endpoints to `src/config/rpcConfig.ts` |
| 137 | +3. Determine if network needs custom fetchers/adapters |
| 138 | +4. If custom: create `src/services/EVM/[Network]/fetchers/` and `adapters/` |
| 139 | +5. Update `DataService` constructor to detect chain ID |
| 140 | +6. Add network config to `ALL_NETWORKS` in `src/config/networks.ts` |
| 141 | +7. Add network logo to `public/` and update `logoType` in network config |
| 142 | + |
| 143 | +## Code Style |
| 144 | + |
| 145 | +- **Formatter/Linter**: Biome (see `biome.json`) |
| 146 | +- **Line Width**: 100 characters |
| 147 | +- **Indentation**: 2 spaces |
| 148 | +- **TypeScript**: Strict mode enabled |
| 149 | +- **CSS**: Place styles in `src/styles/`, avoid inline styles |
| 150 | + |
| 151 | +## Testing with Local Networks |
| 152 | + |
| 153 | +For development with local blockchain networks: |
| 154 | + |
| 155 | +```bash |
| 156 | +npm run dev |
| 157 | +``` |
| 158 | + |
| 159 | +This starts a Hardhat node with sample contracts and OpenScan pointing to it. |
| 160 | + |
| 161 | +## Questions? |
| 162 | + |
| 163 | +If you have questions or need help, feel free to open an issue on GitHub. |
0 commit comments