tl;dr: join Discord, be courteous, follow the steps below to set up a development environment; if you stick around and contribute, you can join the team and get commit access.
If you are here because you just want to test the bleeding-edge (unreleased) DevTools functionality, follow our beta testing guidance.
We gladly accept contributions via GitHub pull requests! We encourage you to read the Welcome remarks in the Flutter framework's contributing guide, as all of that information applies to contributing to the flutter/devtools repo as well.
We communicate primarily over GitHub and Discord on the #hackers-devtools channel.
Before contributing code:
Complete the Contributor License Agreement. You can do this online, and it only takes a minute.
Review the DevTools style guide, which uses a combination of Dart and Flutter best practices.
Before setting up your DevTools environment, please make sure you have cloned the Flutter SDK from GitHub and added the included flutter and dart executables to your PATH environment variable (see Flutter instructions for how to update your PATH).
Typing which flutter and which dart (or where.exe flutter and where.exe dart for Windows) into your terminal should print the path to the binaries from the Flutter SDK you cloned from GitHub.
Be sure to run flutter doctor -v to ensure your Flutter environment is set up correctly. If you plan to develop on macOS or run a test app on an iOS simulator, you will need to ensure CocoaPods is setup correctly.
Fork the DevTools repo to your own Github account, and then clone it using SSH.
Ensure that you have access to the DevTools repo management tool exectuable, dt:
flutter pub get on the devtools/tool directorydevtools/tool/bin folder to your PATH environment variable:add the following to your ~/.zshrc file (or ~/.bashrc, ~/.bash_profile if you use Bash), replacing <DEVTOOLS_DIR> with the absolute path to your DevTools repo:
export PATH=$PATH:<DEVTOOLS_DIR>/tool/bin
Path variable and click Edit<DEVTOOLS_DIR>/tool/bin, replacing <DEVTOOLS_DIR> with the absolute path to your DevTools repo.Explore the commands and helpers that dt provides by running dt -h.
Optional: enable and activate DCM (Dart Code Metrics) - see the DCM section below
We recommend using VS Code for your DevTools development environment because this gives you access to some advanced development and configuration features. When you open DevTools in VS Code, open the top-level devtools/ directory in your VS Code workspace. This will give you access to a set of launch configurations for running and debugging DevTools:
Ensure your local Flutter SDK, DevTools dependencies, and generated code are up-to-date:
dt sync --update-on-path
Warning: this will delete any local changes in your Flutter SDK you checked out from git.
Create a branch from your cloned DevTools repo:
git checkout -b myBranch
Implement your changes, and commit to your branch:
git commit -m “description”
If your improvement is user-facing, document it in the same PR.
Push to your branch to GitHub:
git push origin myBranch
Navigate to the Pull Requests tab in the main DevTools repo. You should see a popup to create a pull request from the branch in your cloned repo to the DevTools master branch. Create a pull request.
If at any time you need to re-sync your branch, run:
dt sync
This command will:
tool/flutter-sdk to the Flutter version DevTools is built and tested with on the CIOptionally, pass the --update-on-path flag to also update your local Flutter SDK git checkout along with the tool/flutter-sdk.
If you want to upgrade dependencies and re-generate code (like mocks), but do not want to merge upstream/master or update your Flutter SDK version, instead run
dt generate-code --upgrade
To update DCM to the same version as on GitHub bots with apt-get or brew:
Locate, copy and run the apt-get command searching by searching for “install dcm” in build.yaml.
Using the DCM version you just copied in the previous step (without the -1 suffix), install dcm using homebrew: brew install cqlabs/dcm/dcm@<version on bots without -1>
You can check your local version to verify it matches the version in build.yaml: dcm --version.
If the version of DCM used on the bots is outdated, consider contributing a PR to update the version on the bots to the latest.
Please see DEBUGGING.md for guidance on running and debugging DevTools.
Please see TESTING.md for guidance on running and writing tests.
Enabling and activating DCM is optional. When you open a PR, the CI bots will show you any DCM warnings introduced by your change which should be fixed before submitting.
Contributors who work at Google: you can use the Google-purchased license key to activate DCM. See go/dash-devexp-dcm-keys.
All other contributors: please follow instructions at https://dcm.dev/pricing/. You can either use the free tier of DCM, or purchase a team license. Note that the free tier doesn't support all the rules of the paid tier, so you will also need to consult the output of the Dart Code Metrics workflow on Github when you open your PR.
To enable DCM:
dcm activate --license-key=YOUR_KEY from the console.Note: DCM issues can be distinguished from the Dart analyzer issues by their name: DCM rule names contain dashes
-instead of underscores_. Some of the issues can be fixed via CLI; to do so, rundcm fixfor any directory. To applydcm fixon a file save in the IDE, refer to this guide.
All content not authored by the Flutter team (which includes both sponsored and open-source contributors) must go in the third_party directory. As an expedient to make the third_party code works well with our build scripts, code in third_party should be given a stub pubspec.yaml file so that you can reference the resources from the packages directory from packages/devtools_app/web/index.html.