|
| 1 | +# Contributing to OpenCode |
| 2 | + |
| 3 | +We want to make it easy for you to contribute to OpenCode. Here are the most common type of changes that get merged: |
| 4 | + |
| 5 | +- Bug fixes |
| 6 | +- Additional LSPs / Formatters |
| 7 | +- Improvements to LLM performance |
| 8 | +- Support for new providers |
| 9 | +- Fixes for environment-specific quirks |
| 10 | +- Missing standard behavior |
| 11 | +- Documentation improvements |
| 12 | + |
| 13 | +However, any UI or core product feature must go through a design review with the core team before implementation. |
| 14 | + |
| 15 | +> [!IMPORTANT] |
| 16 | +> We do not accept PRs for core features. |
| 17 | +
|
| 18 | +Take a look at recent git history to understand what usually lands. |
| 19 | + |
| 20 | +If you are unsure if a PR would be accepted, feel free to ask a maintainer or look for issues with either of the following labels: |
| 21 | + |
| 22 | +- `help wanted` |
| 23 | +- `bug` |
| 24 | + |
| 25 | +> [!NOTE] |
| 26 | +> PRs that ignore these guardrails will likely be closed. |
| 27 | +
|
| 28 | +Want to take on an issue? Leave a comment and a maintainer may assign it to you unless it is something we are already working on. |
| 29 | + |
| 30 | +## Developing OpenCode |
| 31 | + |
| 32 | +- Requirements: Bun 1.3+, Go 1.24.x. |
| 33 | +- Install dependencies and start the dev server from the repo root: |
| 34 | + |
| 35 | + ```bash |
| 36 | + bun install |
| 37 | + bun dev |
| 38 | + ``` |
| 39 | + |
| 40 | +- Core pieces: |
| 41 | + - `packages/opencode`: OpenCode core business logic & server. |
| 42 | + - `packages/tui`: The TUI code, written in Go (will be removed soon in favor of [opentui](https://github.com/sst/opentui)) |
| 43 | + - `packages/plugin`: Source for `@opencode-ai/plugin` |
| 44 | + |
| 45 | +> [!NOTE] |
| 46 | +> After touching `packages/opencode/src/server/server.ts`, the OpenCode team must regenerate the Stainless SDK before any client updates merge. |
| 47 | +
|
| 48 | +## Pull Request Expectations |
| 49 | + |
| 50 | +- Try to keep pull requests small and focused. |
| 51 | +- Link relevant issue(s) in the description |
| 52 | +- Explain the issue and why your change fixes it |
| 53 | +- Avoid having verbose LLM generated PR descriptions |
| 54 | +- Before adding new functions or functionality, ensure that such behavior doesn't already exist elsewhere in the codebase. |
| 55 | + |
| 56 | +### Style Preferences |
| 57 | + |
| 58 | +These are not strictly enforced, they are just general guidelines: |
| 59 | + |
| 60 | +- **Functions:** Keep logic within a single function unless breaking it out adds clear reuse or composition benefits. |
| 61 | +- **Destructuring:** Do not do unnecessary destructuring of variables. |
| 62 | +- **Control flow:** Avoid `else` statements. |
| 63 | +- **Error handling:** Prefer `.catch(...)` instead of `try`/`catch` when possible. |
| 64 | +- **Types:** Reach for precise types and avoid `any`. |
| 65 | +- **Variables:** Stick to immutable patterns and avoid `let`. |
| 66 | +- **Naming:** Choose concise single-word identifiers when they remain descriptive. |
| 67 | +- **Runtime APIs:** Use Bun helpers such as `Bun.file()` when they fit the use case. |
| 68 | + |
| 69 | +## Feature Requests |
| 70 | + |
| 71 | +For net-new functionality, start with a design conversation. Open an issue describing the problem, your proposed approach (optional), and why it belongs in OpenCode. The core team will help decide whether it should move forward; please wait for that approval instead of opening a feature PR directly. |
0 commit comments