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:
- Well tested
Are much more likely to get reviewed and merged in a timely manner.
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:
On your local file system:
├── cornerstonejs/cornerstone-tools└── ohif/viewers
- Open a terminal/shell
- Navigate to
yarn run dev
- Open a new terminal/shell
- Navigate to
ohif/viewers(the root of ohif project)
yarn link cornerstone-tools
yarn run dev
As you make changed to
cornerstone-tools, and it's output is rebuilt, you
should see the following behavior:
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
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.
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.