5cb2fb41f8
Merging for testing since this can't be tested without a merge to master
fix(ci): use --no-frozen-lockfile for docs deploy (pnpm migration)
The Build and Deploy Docs workflow ran `pnpm install --frozen-lockfile` and
failed on every master push after the pnpm migration:
[ERR_PNPM_OUTDATED_LOCKFILE] pnpm-lock.yaml is not up to date with
platform/core/package.json
- @ohif/ui (lockfile: workspace:*, manifest: 3.13.0-beta.90)
publish-version.mjs rewrites @ohif/* workspace deps from "workspace:*" to the
concrete release version and commits that bump to master, so the committed
manifests intentionally drift from pnpm-lock.yaml. Every CircleCI job already
passes --no-frozen-lockfile for exactly this reason (pnpm-workspace.yaml sets
frozenLockfile:true as the default); the docs workflow was the lone job still
using frozen and so broke the docs deploy.
Switch the docs install to --no-frozen-lockfile to match the rest of CI.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@
* fix(ci): write npm auth token to ~/.npmrc so publishes authenticate
NPM_PUBLISH wrote the registry auth token to ~/repo/.npmrc (the repo root),
but publish-package.mjs does process.chdir(packageDirectory) and runs
`npm publish` from inside each package (platform/ui, extensions/*, ...). npm
reads the project .npmrc from that package dir and the user .npmrc from
$HOME -- it never walks up to ~/repo/.npmrc -- so every publish failed with
ENEEDAUTH ("need auth ... requires you to be logged in").
publish-package.mjs catches and swallows per-package publish errors, so
NPM_PUBLISH still exited 0 and reported green; the breakage was silent. As a
result no @ohif/* package newer than 3.13.0-beta.89 (the last publish before
the pnpm migration) reached npm -- beta.90 and beta.91 are missing and the
beta dist-tag is stuck at beta.89.
Write the token to ~/.npmrc (npm per-user config, read regardless of cwd)
instead. This also stops clobbering the committed workspace-config .npmrc
(node-linker=hoisted) at the repo root, which the in-job pnpm install/build
relies on. Applied to all three auth steps for consistency.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(docker): copy preinstall.js before pnpm install in builder stage
The builder stage copies only the package.json manifests, runs
`pnpm install --no-frozen-lockfile`, and copies the rest of the source
afterward (for layer caching). But the root package.json defines a
"preinstall" lifecycle script (node preinstall.js) that pnpm runs at the
start of install -- before the source copy -- so the script file was absent
and install aborted:
. preinstall$ node preinstall.js
Error: Cannot find module '/usr/src/app/preinstall.js' (MODULE_NOT_FOUND)
ERROR: process "pnpm install --no-frozen-lockfile" did not complete
This surfaced once the .npmrc COPY fix (#6076) let the build advance past
the earlier COPY failure. preinstall.js is self-contained (it no-ops without
GITHUB_TOKEN and guards the AGENTS.md/CLAUDE.md symlink with existsSync), so
copying just the script into the early manifest layer is sufficient.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(build): declare postcss plugins in platform/app for Docker build
The shared root postcss.config.js (which platform/app re-exports) loads
postcss-import, postcss-preset-env, and cssnano, but none were declared in
platform/app or the root. They only reached node_modules by being hoisted
from platform/docs (postcss-import, postcss-preset-env) and transitively
(cssnano). The Docker image excludes platform/docs via .dockerignore and
libs/@cornerstonejs is not a workspace member, so under pnpm's stricter
node-linker=hoisted the app build failed to resolve the plugins:
Loading PostCSS "postcss-preset-env" plugin failed:
Cannot find module 'postcss-preset-env'
(The accompanying "Can't resolve assets/woff2/latin.woff2" error was a
cascade from the broken PostCSS chain and clears with this fix.)
Declare the three plugins the config explicitly loads as devDependencies of
platform/app, pinned to the versions already resolved by working builds
(postcss-import@14.1.0, postcss-preset-env@7.8.3, cssnano@5.1.15), so the
build no longer depends on incidental hoisting from docs.
The lockfile was regenerated against a workspace:* baseline so the only
@ohif change is none -- the diff adds just the postcss plugin trees, keeping
specifiers at workspace:* per the repo's convention. Verified by building the
full Docker image locally: rspack compiles with 0 errors and the image
exports successfully.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| .recipes | ||
| .webpack | ||
| assets | ||
| cypress | ||
| public | ||
| src | ||
| .all-contributorsrc | ||
| .browserslistrc | ||
| .dockerignore | ||
| .env | ||
| .env.example | ||
| .eslintignore | ||
| .gitignore | ||
| babel.config.js | ||
| CHANGELOG.md | ||
| cypress.config.ts | ||
| jest.config.js | ||
| jestBabelTransform.js | ||
| LICENSE | ||
| package.json | ||
| pluginConfig.json | ||
| postcss.config.js | ||
| preinstall.js | ||
| README.md | ||
| tailwind.config.js | ||
| tailwind.css | ||
@ohif/app
@ohif/app is a zero-footprint medical image viewer provided by the Open Health Imaging Foundation (OHIF). It is a configurable and extensible progressive web application with out-of-the-box support for image archives which support DICOMweb.
ATTENTION: If you are looking for Version 1 (the Meteor Version) of this repository, it lives on the
v1.xbranch
Why?
Building a web based medical imaging viewer from scratch is time intensive, hard to get right, and expensive. Instead of re-inventing the wheel, you can use the OHIF Viewer as a rock solid platform to build on top of. The Viewer is a React Progressive Web Application that can be embedded in existing applications via it's packaged source (ohif-viewer) or hosted stand-alone. The Viewer exposes configuration and extensions to support workflow customization and advanced functionality at common integration points.
If you're interested in using the OHIF Viewer, but you're not sure it supports your use case check out our docs. Still not sure, or you would like to propose new features? Don't hesitate to create an issue or open a pull request.
Getting Started
This readme is specific to testing and developing locally. If you're more interested in production deployment strategies, you can check out our documentation on publishing.
Want to play around before you dig in? Check out our LIVE Demo
Setup
Requirements:
Steps:
- Fork this repository
- Clone your forked repository (your
origin)
git clone git@github.com:YOUR_GITHUB_USERNAME/Viewers.git
- Add
OHIF/Viewersas aremoterepository (theupstream)
git remote add upstream git@github.com:OHIF/Viewers.git
Developing Locally
In your cloned repository's root folder, run:
// Restore dependencies
yarn install --frozen-lockfile
// Stands up local server to host Viewer.
// Viewer connects to our public cloud PACS by default
yarn start
For more advanced local development scenarios, like using your own locally hosted PACS and test data, check out our Essential: Getting Started guide.
E2E Tests
Using Cypress to create End-to-End tests and check whether the application flow is performing correctly, ensuring that the integrated components are working as expected.
Why Cypress?
Cypress is a next generation front end testing tool built for the modern web. With Cypress is easy to set up, write, run and debug tests
It allow us to write different types of tests:
- End-to-End tests
- Integration tests
- Unit tets
All tests must be in ./cypress/integration folder.
Commands to run the tests:
// Open Cypress Dashboard that provides insight into what happened when your tests ran
yarn run cy
// Run all tests using Electron browser headless
yarn run cy:run
// Run all tests in CI mode
yarn run cy:run:ci
Contributing
Large portions of the Viewer's functionality are maintained in other repositories. To get a better understanding of the Viewer's architecture and "where things live", read our docs on the Viewer's architecture
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. 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 - 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.
Contributors
Thanks goes to these wonderful people (emoji key):
 Erik Ziegler 💻 🚇 |  Evren Ozkan 💻 |  Gustavo André Lelis 💻 |  Danny Brown 💻 🚇 | ![allcontributors[bot]](https://avatars3.githubusercontent.com/u/46843839?v=4) allcontributors[bot] 📖 |  Esref Durna 💬 |  diego0020 💻 |
 David Wire 💻 |  João Felipe de Medeiros Moreira ⚠️ |
This project follows the all-contributors specification. Contributions of any kind welcome!
License
MIT © OHIF