Skip to main content
Version: 3.8

Contributing

How can I help?​

Fork the repository, make your change and submit a pull request. If you would like to discuss the changes you intend to make to clarify where or how they should be implemented, please don't hesitate to create a new issue. At a minimum, you may want to read the following documentation:

Pull requests that are:

Are much more likely to get reviewed and merged in a timely manner.

When changes impact multiple repositories​

While this can be tricky, we've tried to reduce how often this situation crops up this with our recent switch to a monorepo. Our maintained extensions, ui components, internationalization library, and business logic can all be developed by simply running yarn run dev from the repository root.

Testing the viewer with locally developed, unpublished package changes from a package outside of the monorepo is most common with extension development. Let's demonstrate how to accomplish this with two commonly forked extension dependencies:

cornerstone-tools​

On your local file system:

/my-projects/
├── cornerstonejs/cornerstone-tools
└── ohif/viewers
  • Open a terminal/shell
  • Navigate to cornerstonejs/cornerstone-tools

As you make changed to cornerstone-tools, and it's output is rebuilt, you should see the following behavior:

tools

If you wish to stop using your local package, run the following commands in the ohif/viewers repository root:

  • yarn unlink cornerstone-tools
  • yarn install --force

Other linkage notes​

We're still working out some of the kinks with local package development as there are a lot of factors that can influence the behavior of our development server and bundler. If you encounter issues not addressed here, please don't hesitate to reach out on GitHub.

Sometimes you might encounter a situation where the linking doesn't work as expected. This might happen when there are multiple linked packages with the same name. You can remove the linked packages inside yarn and try again.

Any guidance on submitting changes?​

While we do appreciate code contributions, triaging and integrating contributed code changes can be very time consuming. Please consider the following tips when working on your pull requests:

  • Functionality is appropriate for the repository. Consider creating a GitHub issue to discuss your suggested changes.
  • The scope of the pull request is not too large. Please consider separate pull requests for each feature as big pull requests are very time consuming to understand.

We will provide feedback on your pull requests as soon as possible. Following the tips above will help ensure your changes are reviewed.