cornerstonejs / cornerstone3D

Cornerstone is a set of JavaScript libraries that can be used to build web-based medical imaging applications. It provides a framework to build radiology applications such as the OHIF Viewer.
https://cornerstonejs.org
MIT License
572 stars 291 forks source link

[Bug] yarn install leads to duplicate @cornerstone packages, which in turn leads to critical errors, if a cornerstone version is fixed in package.json (npm works fine) #1024

Open vnosikov opened 9 months ago

vnosikov commented 9 months ago

Describe the Bug

A user may decide to use a fixed cornerstone version. Imagine she configures her package.json like this:

    "@cornerstonejs/core": "1.44.3",
    "@cornerstonejs/dicom-image-loader": "1.44.3",
    "@cornerstonejs/streaming-image-volume-loader": "1.44.3",
    "@cornerstonejs/tools": "1.44.3",

However packages of @cornerstonejs/tools, @cornerstonejs/streaming-image-volume-loader and @cornerstonejs/dicom-image-loaderare also dependent on @cornerstonjs/core. And their package.json use caret versions.

For example, https://github.com/cornerstonejs/cornerstone3D/blob/v1.44.3/packages/tools/package.json:

 "dependencies": {
    "@cornerstonejs/core": "^1.44.3",
    [...]
  },

So what happens when a user install dependencies? Turns out it depends on her package manager. npm dedupes newer versions and the user gets 1.44.3 as she expected. However yarn will install both 1.44.3 and the latest caret versions (Right now it is 1.47.4, so going forward I will use this tag).

So now when a user calls cornerstone, she uses 1.44.3 version. However when cornerstone-tools calls anything from cornerstone they reach to 1.47.4 version. Usually it breaks the app very fast, as for example tools can not address a rendering engine. It was dutifully stored in a renderingEngineCache, but it was a renderingEngineCache of a version 1.44.3 and renderingEngineCache of a version 1.47.4 is empty, so please take this white screen of death and good luck with debugging it.

You can work-around this either by using only npm, or by configuring overrides/resolutions in package.json. However this problem can be extremely painful for an unprepared user. I kindly ask you to use only fixed versions of cornerstone-related dependencies in your packages. If for some reason you don't want to do it, please add some information in documentation about this pitfall.

Steps to Reproduce

  1. Set fixed versions of cornerstone-related packages in your package.json
    "@cornerstonejs/core": "1.44.3",
    "@cornerstonejs/dicom-image-loader": "1.44.3",
    "@cornerstonejs/streaming-image-volume-loader": "1.44.3",
    "@cornerstonejs/tools": "1.44.3",
  2. Run yarn install
  3. Run yarn list @cornerstonejs/core
    
    ├─ @cornerstonejs/core@1.44.3
    ├─ @cornerstonejs/dicom-image-loader@1.44.3
    │  └─ @cornerstonejs/core@1.47.4
    ├─ @cornerstonejs/streaming-image-volume-loader@1.44.3
    │  └─ @cornerstonejs/core@1.47.4
    └─ @cornerstonejs/tools@1.44.3
    └─ @cornerstonejs/core@1.47.4
4. Notice that there are different packages of `@cornerstonejs/core` installed 

### The current behavior

If a user specifies a fixed versions of @cornerstone-related packages in her `package.json `and then run yarn install she will get duplicated packages of` @cornerstonejs/core` with different versions.

### The expected behavior

With npm a deduplication procedure works just fine

1. Set fixed versions of cornerstone-related packages in your package.json
"@cornerstonejs/core": "1.44.3",
"@cornerstonejs/dicom-image-loader": "1.44.3",
"@cornerstonejs/streaming-image-volume-loader": "1.44.3",
"@cornerstonejs/tools": "1.44.3",
2. Run `npm install`
3. Run `npm ls @cornerstonejs/core`

├── @cornerstonejs/core@1.44.3 ├─┬ @cornerstonejs/dicom-image-loader@1.44.3 │ └── @cornerstonejs/core@1.44.3 deduped ├─┬ @cornerstonejs/streaming-image-volume-loader@1.44.3 │ └── @cornerstonejs/core@1.44.3 deduped └─┬ @cornerstonejs/tools@1.44.3 └── @cornerstonejs/core@1.44.3 deduped


4. Notice that newer versions are ignored and all but the one package are deduped.

### OS

Ubuntu 22.04

### Node version

20.10.0

### Browser

Firefox 121.0
danielraggs commented 5 months ago

I ran into the exact same issue and had no idea separate renderingEngineCache instances were being created per resolved version of @cornerstone/core. Thanks so much for this workaround!

vnosikov commented 5 months ago

I ran into the exact same issue and had no idea separate renderingEngineCache instances were being created per resolved version of @cornerstone/core. Thanks so much for this workaround!

You are welcome. Debugging this was truly a mind-blowing experience; I am glad it is useful to other people too

vnosikov commented 5 months ago

@sedghi why did you close this issue? Yes, I provided a workable workaround, but the underlying issue stands and I guess you should either change your inter-package dependencies to fixed versions (I checked the last version they are still caret) or at least explicitly describe this pitfall in a documentation. Is there any reason no to do so?

plt-joey commented 2 months ago

@sedghi This is still an issue, please re-open

sedghi commented 1 day ago

I think this is fixed in Cornerstone3D 2.0 since others have core as peerDependency, please check

Here are the migration guides:

Try OHIF locally: https://viewer-dev.ohif.org/localbasic
Try Cornerstone3D 2.0 locally: https://www.cornerstonejs.org/live-examples/local.html

https://docs.ohif.org/migration-guide/3p8-to-3p9/