How to Contribute
There are many ways to contribute to the Azure Data Studio project: logging bugs, submitting pull requests, reporting issues, and creating suggestions.
Read the developer getting started guide here
From a terminal, where you have cloned the azuredatastudio repository, execute the following command to run the TypeScript incremental builder:
yarn run watchIt will do an initial full build and then watch for file changes, compiling those changes incrementally, enabling a fast, iterative coding experience.
You can either use VS Code or the Chrome Developer Tools to debug Azure Data Studio.
-
Install the Debugger for Chrome extension and JavaScript Debugger (Nightly) extension. these extensions will let you attach to and debug client side code running in Chrome.
-
Open the
azuredatastudiorepository folder -
Choose the
Launch azuredatastudiolaunch configuration from the launch dropdown in the Debug viewlet and pressF5.
This will launch and attach to the main renderer process (for code under src). To debug extensions under the extensions folder use the Debug Renderer and Extension Host processes launch configuration.
-
Run the
Developer: Toggle Developer Toolscommand from the Command Palette in your development instance of Azure Data Studio to launch the Chrome tools. -
It's also possible to debug the released versions of Azure Data Studio, since the sources link to sourcemaps hosted online.
Run the unit tests directly from a terminal by running ./scripts/test.sh from the azuredatastudio folder (scripts\test on Windows). The test README has complete details on how to run and debug tests, as well as how to produce coverage reports.
Run the integration tests directly from a terminal by running ./scripts/sql-test-integration.sh from the azuredatastudio folder (scripts\sql-test-integration.bat on Windows).
To debug the integration tests, run the script mentioned above and then attach to the extension host.
(Windows only for now) Run the smoke tests directly from a terminal by running node test\index.js from the azuredatastudio\test\smoke\ folder.
To debug the smoke test, in VSCode, select Launch Smoke Test from the launch option.
We use tslint for linting our sources. You can run tslint across the sources by calling gulp tslint from a terminal or command prompt.
To lint the source as you make changes you can install the tslint extension.
Even if you have push rights on the Microsoft/azuredatastudio repository, you should create a personal fork and create feature branches there when you need them. This keeps the main repository clean and your personal workflow cruft out of sight.
Before we can accept a pull request from you, you'll need to sign a Contributor License Agreement (CLA). It is an automated process and you only need to do it once.
To enable us to quickly review and accept your pull requests, always create one pull request per issue and link the issue in the pull request. Never merge multiple requests in one unless they have the same root cause. Be sure to follow our coding guidelines and keep code changes as small as possible. Avoid pure formatting changes to code that has not been modified otherwise. Pull requests should contain tests whenever possible.
Check out the full issues list for a list of all potential areas for contributions.
To improve the chances to get a pull request merged you should select an issue that is labelled with the help-wanted or bug labels. If the issue you want to work on is not labelled with help-wanted or bug, you can start a conversation with the issue owner asking whether an external contribution will be considered.
We're also interested in your feedback for the future of Azure Data Studio. You can submit a suggestion or feature request through the issue tracker. To make this process more effective, we're asking that these include more information to help define them more clearly.
In order to keep the conversation clear and transparent, please limit discussion to English and keep things on topic with the issue. Be considerate to others and try to be courteous and professional at all times.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.