Describe Your Question
TL;DR
What is the recommended git repository setup for building custom modes / extensions in a way that we can continue to sync changes from the upstream repository frequently?
Context
My team is evaluating options to build an app to explore and manipulate the DICOM datasets that we have. After spending some time with the OHIF documentation, it looks like most of our viewing and annotation use cases are already covered. But we’ll need some custom behavior around the UI to explore the data set, advanced search capabilities etc. From the docs, I understand that the recommended way to customize the viewer is to build extensions and modes that consume them. We do not plan to publish the modes or extensions. We just want them to work together for our customized viewer app.
Questions
Is there a recommended git repository setup for this? How should we organize the repository that contains the source code for our custom modes / extensions and the Viewers (upstream) source code? We would like to sync changes from the upstream repository going forward as well. So I don’t want to make any changes to the files that are tracked in the repository. I would have preferred having a single git repository on our end that holds all this together and I was considering git submodules to keep the Viewers repository as a submodule so that we can sync changes as new commits are added to the upstream repo. But if git submodules is cumbersome, we’re okay with having 2 repositories on our end - one would be a clone of the Viewers repo (where we don’t make any local changes and occasionally sync changes from upstream) and the other being a repository where we maintain the custom modes / extensions that we need for this project.
My concern here is that the development workflow involves changes to the files tracked in the upstream repo. For instance, if I create a custom mode using the CLI provided, it modifies pluginConfig.json and the webpack.pwa.js files which are tracked in the upstream repo. So, I cannot commit these changes. Every time we need to sync changes from the upstream repo, we need to revert (or stash) these changes, pull in the new changes, and then reapply the stashed / reverted changes. Or we need to make sure that we commit to a different dev branch and every time we pull in new changes, we merge the new upstream changes to the dev branch. Is there a better workflow for this?
Another question I have is around config files. I would like to update the data source config to point to our data source. For the same reasons as above, I wouldn’t want to make changes directly to the default.js config file. So, I was considering creating a config file which overrides particular config values from the default config and then having a custom .env file to set that config to the required environment variable. Now the question is, where do I store this env file? Is there a way I can save it outside the Viewers repository but still use it to define environment variables for the app? Is there any other recommended way to extend configs, in a way that does not cause conflicts with syncing changes with the upstream repo later on.
- Which OHIF version you are using?
The latest master branch commit