History

Bill Wallace 256b8347e7 fix(docs): remove stray tool-call tags breaking the MDX build (#6081 ) This is a fix to pnpm deployment which needs testing as the final part of origin/master release No functional changes * fix(docs): remove stray tool-call tags breaking the MDX build platform/docs/docs/migration-guide/3p12-to-3p13/build-tooling.md ended with two orphan closing tags (leftover tool-call serialization artifacts): </content> </invoke> Docusaurus compiles Markdown as MDX (JSX-aware), so the orphan closing tag failed the docs build: MDX compilation failed ... Unexpected closing slash in tag, expected an open tag first (build-tooling.md line 402) This was the remaining blocker for build-and-deploy-docs once the --no-frozen-lockfile change let the install step succeed. A scan of the docs tree found no other such artifacts. Verified locally: docusaurus build now generates static files with no MDX errors. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Update lockfile and avoid freshness check on every command * fix(release): keep workspace:* in the repo, concretize only at publish The release flow rewrote internal @ohif/* dependency specifiers to the concrete version and committed them, so pnpm-lock.yaml (which records workspace links) drifted from the manifests on every version bump. The resulting ERR_PNPM_OUTDATED_LOCKFILE broke every frozen install: Netlify (viewer-dev), the docs deploy, pnpm's pre-run deps check, and post-merge installs. Keep workspace:* everywhere in the committed repo and move the concrete-version substitution to publish time only: - publish-version.mjs: bump each package's own `version` field only; stop rewriting @ohif/* dependency/peerDependency specifiers. - publish-package.mjs: publish with `pnpm publish --no-git-checks` instead of `npm publish`. pnpm rewrites workspace:* to the exact version in the published tarball; npm would publish the literal "workspace:", which npm/yarn consumers cannot resolve. - One-time: revert the 25 workspace manifests' @ohif/ specifiers to workspace:* (version fields untouched) and regenerate pnpm-lock.yaml to match. Because internal deps are workspace:* (links, not versions in the lockfile), version bumps no longer change pnpm-lock.yaml, so it stays in sync and frozen installs keep working. Verified: `pnpm install --frozen-lockfile` passes, and `pnpm pack` of @ohif/core emits a tarball whose @ohif/ui dependency is the exact version (3.13.0-beta.92), not workspace:. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> docs(ci): correct build-docs install comment for workspace:* release flow publish-version.mjs no longer rewrites @ohif/* deps to concrete versions, so the old comment was stale. Internal deps stay workspace:* and the lockfile stays consistent; pnpm publish concretizes only the published tarball. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(docs): use --frozen-lockfile now that the lockfile no longer drifts With internal deps as workspace:* the lockfile stays in sync across version bumps, so the docs deploy can install frozen -- failing fast on genuine lockfile drift instead of silently reconciling. The --no-frozen-lockfile workaround is no longer needed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci: use --frozen-lockfile in CI install steps now that the lockfile is stable Internal @ohif/* deps are workspace:* so pnpm-lock.yaml no longer drifts; the UNIT_TESTS/BUILD/NPM_PUBLISH installs can run frozen and fail fast on genuine drift. Kept --no-frozen-lockfile only where it is still required: the Dockerfile (platform/docs is excluded from the build context) and the playwright CS3D-version step (mutates @cornerstonejs versions before installing). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test: stability of seg load mpr test * Better drag fix for crosshairs --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>		2026-06-16 11:59:04 -04:00
..
.webpack	feat: Update to use pnpm (#6031 )	2026-06-12 16:04:56 -04:00
src	fix: ohif tests to run with cornerstone 3d 5.0 (#6043 )	2026-06-09 20:25:14 -04:00
.all-contributorsrc	chore(prettier): full repo linting and code reformatting once and for all (#3627 )	2023-09-01 16:19:39 -04:00
babel.config.js	chore(prettier): full repo linting and code reformatting once and for all (#3627 )	2023-09-01 16:19:39 -04:00
CHANGELOG.md	chore(version): Update package versions to 3.13.0-beta.89 [skip ci]	2026-06-10 00:29:36 +00:00
jest.config.js	feat: customization service append and customize functionality should run once (#4238 )	2024-06-19 16:31:59 -04:00
LICENSE	Chore/kill yalc with fire (#629 )	2019-08-13 15:36:46 -04:00
package.json	fix(docs): remove stray tool-call tags breaking the MDX build (#6081 )	2026-06-16 11:59:04 -04:00
README.md	fix(security): For bun, enforce frozen lockfile. For yarn, strongly suggest using frozen lockfile. (#5508 )	2025-10-24 16:48:35 -04:00

README.md

@ohif/core

@ohif/core is a collection of useful functions and classes for building web-based medical imaging applications. This library helps power OHIF's zero-footprint DICOM viewer.

Why?

This library offers pre-packaged solutions for features common to Web-based medical imaging viewers. For example:

Hotkeys
DICOM Web
Hanging Protocols
Managing a study's measurements
Managing a study's DICOM metadata
A flexible pattern for extensions
And many others

It does this while remaining decoupled from any particular view library or rendering logic. While we use it to power our React Viewer, it can be used with Vue, React, Vanilla JS, or any number of other frameworks.

Getting Started

The documentation for this library is sparse. The best way to get started is to look at its top level exports, and explore the source code of features that interest you. If you want to see how we use this library, you can check out our viewer implementation.

Install

This library is pre- v1.0. All releases until a v1.0 have the possibility of introducing breaking changes. Please depend on an "exact" version in your projects to prevent issues caused by loose versioning.

// with npm
npm i @ohif/core --save-exact

// with yarn
yarn add @ohif/core --exact

Usage

Usage is dependent on the feature(s) you want to leverage. The bulk of @ohif/core's features are "pure" and can be imported and used in place.

Example: retrieving study metadata from a server

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

const studiesMetadata = await studies.retrieveStudiesMetadata(
  server, // Object
  studyInstanceUIDs, // Array
  seriesInstanceUIDs // Array (optional)
);

Contributing

It is notoriously difficult to setup multiple dependent repositories for end-to-end testing and development. That's why we recommend writing and running unit tests when adding and modifying features for this library. This allows us to program in isolation without a complex setup, and has the added benefit of producing well-tested business logic.

Clone this repository
Navigate to the project directory, and yarn install --frozen-lockfile
To begin making changes, yarn run dev
To commit changes, run yarn run cm

When creating tests, place the test file "next to" the file you're testing. For example:

// File
index.js;

// Test for file
index.test.js;

As you add and modify code, jest will watch for uncommitted changes and run your tests, reporting the results to your terminal. Make a pull request with your changes to master, and a core team member will review your work. If you have any questions, please don't hesitate to reach out via a GitHub issue.