docs/contribution-guide/index.md
Contributions are always welcome, no matter how large or small! Here we summarize some general guidelines on how you can get involved in the Rolldown project.
All development happens directly on GitHub. Both core team members and external contributors (via forks) send pull requests which go through the same review process.
Outside of GitHub, we also use a Discord server for real-time discussions.
When using AI tools (including LLMs like ChatGPT, Claude, Copilot, etc.) to contribute to Rolldown:
We encourage the use of AI tools to assist with development, but all contributions must be thoroughly reviewed and tested by the contributor before submission. AI-generated code should be understood, validated, and adapted to meet Rolldown's standards.
Please open a bug report on GitHub only after searching the existing issues and finding no match. Be as descriptive as possible, and include all applicable labels.
The best way to get your bug fixed is to include a minimal reproduction — a public repository with a runnable example, a usable code snippet, or a link to our REPL for a quick in-browser repro.
Before requesting new functionality, search the open issues — someone may have requested it already. If not, open an issue with the title prefixed with [request]. Be as descriptive as possible, and include all applicable labels.
We welcome pull requests for bugs, fixes, improvements, and new features. Before you open one, please check which of the two paths below applies to your change: send it directly, or discuss the approach first. Either way, be sure your build passes locally before you submit.
For setting up the project's development environment, see Project Setup.
[!NOTE] Please read the Etiquette chapter before submitting a pull request.
No prior discussion is needed for changes whose correctness speaks for itself:
If there's a related issue, link it in your pull request.
For the changes below, please open or comment on an issue and reach agreement with the team before you start coding or open a pull request:
For these changes, the hard part is usually agreeing on the right direction, not writing the code. Talking it through first means your work goes into something we can merge, instead of stalling while the direction is still being worked out.
If you open a pull request in this category without that agreement, we may close it. Closing it is not a rejection of your work, or of you as a contributor. It only means the change needs to go through the discussion process first. If you want to drive it forward, share your thinking on the linked issue or in our Discord — once there's agreement on the direction, the pull request is very welcome.
If your pull request is still a work in progress, please open it as a draft and only mark it Ready for review once you genuinely want the team to review it. Converting a PR to "Ready for review" notifies reviewers and code owners, so please hold off until your changes are complete and your build passes locally. This keeps maintainers' inboxes focused on PRs that actually need attention.
Submit all pull requests directly to the main branch. We only use separate branches for upcoming releases or breaking changes; otherwise, everything targets main.
Code that lands in main must be compatible with the latest stable release. It may contain additional features, but no breaking changes. We should be able to release a new minor version from the tip of main at any time.