Viewers
Viewers copied to clipboard
[Bug] no exported member named 'hotkeys' & cannot find module '@ohif/mode-longitudinal'
Describe the Bug
This is a follow-up for https://github.com/OHIF/Viewers/issues/3979
Steps to Reproduce
- Checkout and install ohif
- Create and link a mode anywhere except
Viewers/modes - Open up created mode
src/index.tsxin 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)
Error 2
import { initToolGroups, toolbarButtons } from '@ohif/mode-longitudinal';
produces an error: TS2307: Cannot find module @ohif/mode-longitudinal or its corresponding type declarations.
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.
The expected behavior
Imports work without errors.
OS
macOS 14.5 (23F79)
Node version
v18.19.0
Browser
No browser needed
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.
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.
cd Viewers/platform/coreyarn linkcd extensions/custom-extensionsyarn 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.
cd Viewerstsc --declarationMap --outDir ../typings. This will generate a bunch of.d.tsand.d.ts.mapfiles.cd extension/custom-extension- create a
tsconfig.sjsonfile 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!
This is awesome debugging , thanks a lot. We will enhance it further
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.
Any progress on this? I am not able to properly setup OHIF in WebStorm, unfortunately.
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.
see the migration guides https://docs.ohif.org/migration-guide/3p9-to-3p10/General/hotkeys