Home

Welcome

Welcome to the Microsoft Graph Toolkit Wiki. These pages are primarily intended for those who wish to contribute to the project by submitting bug reports, suggesting new features, building extensions, commenting on new ideas, or even by submitting pull requests.

Please refer to the sidebar (on the right) for details on Contributing.

If you are looking for more information on using Microsoft Graph Toolkit, please visit our Documentation and Component Playground!

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Contributing to Microsoft Graph Toolkit

There are many ways to contribute to the Microsoft Graph Toolkit project: logging bugs, submitting pull requests, reporting issues, and creating suggestions.

After cloning and building the repo, check out the issues list. Issues labeled help wanted are good issues to submit a PR for. Issues labeled good first issue are great candidates to pick up if you are in the code for the first time. If you are contributing significant changes, please discuss with the assignee of the issue first before starting to work on the issue.

Keep reading to get setup for contributing code to the Microsoft Graph Toolkit!

• Setup the development environment
• Clone and build the project
• Develop
• Git workflow
• Submitting a pull request and participating in code review
• Quality assurance for new features

For more advanced topic, see the nav bar on the right.

Setup the development environment

Before cloning the repository, make sure you've installed the following prerequisites

Required (in this order)

1. Git (latest version)

2. Node.JS

   If planing to work on the @microsoft/mgt-sharepoint or @microsoft/mgt-spfx packages, please use nodejs v10.

   Otherwise, you should be able to use nodejs v12 or nodejs v14.

3. yarn

in your favorite shell, run npm install -g yarn

Recommended

• VS Code (or your favorite code editor)

  We also recommend to install the workplace recommended extensions once you've opened the cloned project in vscode.

Clone and build the project

1. Clone the repository and navigate to the project root.

   > git clone https://github.com/microsoftgraph/microsoft-graph-toolkit
   
   > cd microsoft-graph-toolkit

2. Install all dependencies

   > yarn

3. Build the project

   > yarn build

NOTE it will take few minutes to install all dependencies and build the project

Developing

There are several ways to "run" the project and test your changes. All have pros and cons and you might find using a combination of these as you are developing and testing changes.

1. yarn start

> yarn start

The main start script will spin up a basic web server and open the browser pointing to the index.html in the root of the repo. This script also will start up the typescript compiler in watch mode which will reload the page as you are changing the code.

While you can use index.html while developing, please DO NOT commit changes to this file in your PR as this would make the file unusable for everyone. Because of this, we recommend using the start:storybook script and writing stories that you can use for testing and commit alongside your PR.

2. yarn start:storybook (RECOMMENDED)

> yarn start:storybook

This script will launch storybook, the local version of mgt.dev. It will also watch for any changes to the source files and reload the story as you are working. See Storybook for how to use storybook for development.

3. Running samples

The repository also contains several samples in the samples folder that make it easier to developer and test specific features. For example, the react-app sample is useful when working on the @microsoft/mgt-react package.

Each samples contains a readme with instructions on how to run it. In most cases, you will be able to navigate to the folder and run start. For example:

> cd ./samples/react-app

> yarn start

Git workflow

The Microsoft Graph Toolkit uses the GitHub flow where most development happens directly on the main branch. The main branch should always be in a healthy state which is ready for release.

If your change is complex, please clean up the branch history before submitting a pull request. You can use git rebase to group your changes into a small number of commits which we can review one at a time.

When completing a pull request, we will generally squash your changes into a single commit. Please let us know if your pull request needs to be merged as separate commits.

Submitting a pull request and participating in code review

Writing a good description for your pull request is crucial to help reviewers and future maintainers understand your change. Make sure to complete the pull request template to avoid delays. More detail is better.

• Link the issue you're addressing in the pull request. Each pull request must be linked to an issue.
• Describe why the change is being made and why you've chosen a particular solution.
• Describe any manual testing you performed to validate your change.
• Ensure the appropriate tests and documentation have been added

Please submit one pull request per issue. Large pull requests which have unrelated changes can be difficult to review.

After submitting a pull request, core members of the project will review your code.

Often, multiple iterations will be needed to responding to feedback from reviewers.

Quality assurance for new features

We encourage developers to follow the following guidance when submitting new features:

1. Ensure the code is properly documented following the jsdoc syntax
2. Update the documentation when necessary
3. Follow the accessibility guidance for web development