Adding cornerstoneTools as workspace

Hello team,

I’ve been using and working on OHIF Viewer for 2 months and I was using yalc to make modifications on ohif-core, react-viewerbase and cornerstoneTools.

I saw that you made a lot of improvements on extension management and I’m now trying to sync my work with you new updates, but I’m having 2 problems :

• cornerstoneTools is still used as dependencies, how could I add it as a workspace ?
• I had added a tool, that was working with my version of the viewer. Now, when I try to use this tool with the new version (and my version of cornerstoneTools), I get cornerstoneTools.js:11846 Unable to find tool "Repulsor" for enabledElement. How are tools managed in the new version (I added it to the cornerstone toolBarModules, and i created a file for it in the tools folder in platform/core/src/measurements/tools). Have I missed another step?

Thanks for the help, and the great work you’ve done for managing extensions!

[MathisGuilhin]

Thank you for this well explained answer, I’ve managed to add it as a local forked-dependencies (I kept the name so I didn’t have to change everyfile), it ended up working.

I think we will consider in the future to use the extension approach that looks better !

[dannyrb]

Package management can be a pain – I’ll try to do my best to explain.

Best: Don’t fork

In CornerstoneTools@3, every tool is a class that, at a minimum, fulfills the contract defined by the internal BaseTool class. This means you can create your tool outside of cornerstone-tools, and still add it as if it were one the tools that come bundled with the library.

import MyMagicToolClass from './MyMagicToolClass/index.js'
import cornerstoneTools from 'cornerstone-tools'

cornerstoneTools.addTool(MyMagicToolClass);

This change is new to cornerstone-tools as of version 3. We rewrote the entire library to make it possible to reduce the need to maintain a fork. It sounds like both of your tools would be great candidates for it.

If you took this approach, you would only need to modify where the Viewer project defines the available tools for react-cornerstone-viewport. One of the options is apiTool, which allows you to pass your own tool class.

No hoist and Yalc

At the repo root, specify that the cornerstone-tools package should not be hoisted. When you run yarn install, if configured correctly, the dependency should live at /platform/viewer/node_modules/cornerstone-tools. Now you should be able to leverage yalc as you normally would in the Viewer project.

Monorepo Package

This one is trickiest. If you change the package name, as you have done, you’ll either need to update every single reference to the new package name, or add an alias in webpack so requests for cornerstone-tools resolve to @ohif/tools.

After the package has been added, and you’re decently sure all references to it will resolve correctly, you’ll need to run yarn install, so yarn workspaces can setup proper symlinks under the hood.

My suggestion to create a new directory was more for clarity. Platform and extensions have specific purposes. Something more explicit like forked-dependencies/* might be more fitting.