Skip to main content
Want to contribute? Great! This guide will help you get started with contributing to the Dart SDK.

​
Ways You Can Contribute

You can help the Dart project in many ways, in addition to contributing code:

​
Documentation Contributions

If you’d like to improve the documentation, you have three options:
  1. Give us feedback:
    • If you’re looking at a page with a bug icon at the upper right, click that icon to report a bug on the page
    • To report an API doc bug, create an SDK issue
  2. Contribute to Dart developer websites such as dart.dev (repo: dart-lang/site-www). For more information, see Writing for Dart and Flutter websites
  3. Improve API reference docs at api.dart.dev by editing doc comments in the Dart SDK repo. For more information, see Effective Dart: Documentation

​
Before You Contribute

​
Sign the CLA

Before we can use your code, you must sign the Google Individual Contributor License Agreement (CLA). The CLA is necessary because you own the copyright to your changes, even after your contribution becomes part of our codebase.
You don’t have to sign the CLA until after you’ve submitted your code for review and a member has approved it, but you must do it before we can put your code into our codebase.
Contributions made by corporations are covered by the Software Grant and Corporate Contributor License Agreement.

​
Coordinate Large Contributions

Before you start working on a larger contribution, you should get in touch with us first through the Dart Issue Tracker with your idea so that we can help out and possibly guide you. Coordinating up front makes it much easier to avoid frustration later on.

​
Setting Up Your Environment

1

Install depot_tools

In order to submit a patch from a local workspace, you need to install the Chromium depot_tools.
2

Get the source code

To work with the Dart code, you need to download and build the development branch. Active development takes place on the main branch.
You must use the gclient tool (fetch)! Using git clone will not get you a functional environment.
Complete instructions are found at Getting The Source.
3

Create a new branch

Create a new branch using git new-branch (a command added by depot_tools):
git new-branch <feature-name>
You can be in any branch when you run git new-branch.
4

Write and commit your code

Make your changes and commit them:
# Write code
git commit
# Continue working...
git commit

​
Keeping Your Branch Updated

As you work, and before you send a patch for review, ensure your branch is merging cleanly to origin/main. We recommend using git rebase-update (a feature added by depot_tools): 
git rebase-update
You can run this command from any branch. This command will:
  • Fetch origin/main
  • Rebase all your open branches
  • Delete cleanly merged branches

​
Submission Methods

All submissions, including submissions by project members, require review. We use the same code-review tools and process as the Chromium project.

​
GitHub Pull Requests

This repository primarily uses Gerrit for code reviews, rather than GitHub PRs. However, you may submit a GitHub PR, e.g. to edit some API documentation.
GitHub PRs are automatically converted into a Gerrit change list (a “CL”) by a copybara-service bot. You can find the link to that CL as a comment left on the PR by the bot. The PR will be automatically closed when the CL is reviewed and landed.

​
Gerrit Code Review

The main flow is to use the Gerrit review system. See the Code Review Workflow page for detailed instructions.

​
Coding Style

The source code of Dart follows: You should familiarize yourself with those guidelines.

​
File Headers

All files in the Dart project must start with the following header: 
// Copyright (c) 2017, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
The year should be a single number (not a range). If you edit an existing file, you don’t have to update the year.

​
Code of Conduct

We pledge to maintain an open and welcoming environment. For details, see our code of conduct.

Build docs developers (and LLMs) love

Get started for freeTalk to us