Viewers icon indicating copy to clipboard operation
Viewers copied to clipboard

[Bug] no exported member named 'hotkeys' & cannot find module '@ohif/mode-longitudinal'

Open salkz opened this issue 1 year ago • 2 comments

Describe the Bug

This is a follow-up for https://github.com/OHIF/Viewers/issues/3979

Steps to Reproduce

  1. Checkout and install ohif
  2. Create and link a mode anywhere except Viewers/modes
  3. Open up created mode src/index.tsx in Visual Studio Code or WebStorm

The current behavior

Visual Studio Code

Error 1

import { hotkeys } from '@ohif/core';

produces an error: '"@ohif/core"' has no exported member named 'hotkeys'. Did you mean 'Hotkey'?ts(2724)

image

Error 2

import { initToolGroups, toolbarButtons } from '@ohif/mode-longitudinal';

produces an error: TS2307: Cannot find module @ohif/mode-longitudinal or its corresponding type declarations. image

WebStorm

Error 1

import { initToolGroups, toolbarButtons } from '@ohif/mode-longitudinal';

produces an error: TS2307: Cannot find module @ohif/mode-longitudinal or its corresponding type declarations. image

The expected behavior

Imports work without errors.

OS

macOS 14.5 (23F79)

Node version

v18.19.0

Browser

No browser needed

salkz avatar Sep 18 '24 11:09 salkz

Also, I just reproduced the original referenced issue as well with this directory structure:

Viewers
extensions
modes

Where Viewers is the checked out repository and modes, extensions are the directories for created modes and extensions respectively.

If the directory structure is:

Viewers
Viewers/custom-extensions
Viewers/custom-modes

then it somewhat resolves importing from @ohif/core without TS2307 error but then we are left with the errors described in this issue.

salkz avatar Sep 18 '24 12:09 salkz

In order to resolve types on your custom extension/mode, you're IDE needs to be able to resolve the @ohif/core module, or rely on a tsconfig.json config file that configure a path where it can resolve those types.

Note that in the extension/mode template, @ohif/core is listed as a peer dependency and won't be installed in your extension's node_module.

If you move the @ohif/core dependency from peerDependencies to devDependencies and re-yarn, it will pull the published package from NPM and install it in your node_modules, however this package is shipped as a minified UMD module and do not provide types (despite the type: /src/types/index.ts in package.json file)


What you can do instead, is yarn link the @ohif/core package from your Viewers repo into your extension one.

  1. cd Viewers/platform/core
  2. yarn link
  3. cd extensions/custom-extensions
  4. yarn link @ohif/core

That will symlink the package at extensions/custom-extensions/node_module/@ohif/core and your IDE will resolves types at src/types. However, this links to type declaration only..


For a better DX, what I ended up doing is compiling OHIF types, with sourcemaps, to a separate folder, and configure my extension to use those types instead.

  1. cd Viewers
  2. tsc --declarationMap --outDir ../typings. This will generate a bunch of .d.ts and .d.ts.map files.
  3. cd extension/custom-extension
  4. create a tsconfig.sjson file with the following content
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@ohif/ui": ["../../typings/platform/ui/src"],
      "@ohif/core": ["../../typings/platform/core/src"],
      "@ohif/extension-cornerstone": [
        "../../typings/extensions/cornerstone/src"
      ]
    }
  },
}

That way, whenever I GoTo declaration on my IDE, it links directly to the OHIF source code in Viewers.

Hope that helps!

Gabsha avatar Oct 18 '24 18:10 Gabsha

This is awesome debugging , thanks a lot. We will enhance it further

sedghi avatar Nov 06 '24 18:11 sedghi

Note that using OHIF 3.8.3 we could compile most of the declaration files despite a few errors, however in 3.9.1 there is an issue with private fields on the MetadataProvider class, which prevents proper compilation of the @ohif/core index file. Apparently private fields of class expression cannot be represented in declaration files (TS4094).

This workaround will allow core/src/index.ts to compile declaration files.

diff --git a/platform/core/src/classes/MetadataProvider.ts b/platform/core/src/classes/MetadataProvider.ts
index d9cc2e3..1381f30 100644
--- a/platform/core/src/classes/MetadataProvider.ts
+++ b/platform/core/src/classes/MetadataProvider.ts
@@ -8,13 +8,13 @@ import toNumber from '../utils/toNumber';
 import combineFrameInstance from '../utils/combineFrameInstance';
 
 class MetadataProvider {
-  private readonly studies: Map<string, any> = new Map();
-  private readonly imageURIToUIDs: Map<string, any> = new Map();
-  private readonly imageUIDsByImageId: Map<string, any> = new Map();
+  readonly studies: Map<string, any> = new Map();
+  readonly imageURIToUIDs: Map<string, any> = new Map();
+  readonly imageUIDsByImageId: Map<string, any> = new Map();
   // Can be used to store custom metadata for a specific type.
   // For instance, the scaling metadata for PET can be stored here
   // as type "scalingModule"
-  private readonly customMetadata: Map<string, any> = new Map();
+  readonly customMetadata: Map<string, any> = new Map();
 
   addImageIdToUIDs(imageId, uids) {
     // This method is a fallback for when you don't have WADO-URI or WADO-RS.

Gabsha avatar Dec 02 '24 16:12 Gabsha

Any progress on this? I am not able to properly setup OHIF in WebStorm, unfortunately.

aschmiri avatar Jan 14 '25 09:01 aschmiri

Could you please try explaining that again? I'm not quite understanding why you couldn't properly set up OHIF in the webstorm. You might see some type errors, but running it shouldn't be a problem.

sedghi avatar Mar 25 '25 15:03 sedghi