256b8347e7
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> |
||
|---|---|---|
| .. | ||
| .webpack | ||
| src | ||
| babel.config.js | ||
| CHANGELOG.md | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
Test Extension
This extension will provide uitlities and module to help with testing. It is not intended to be used in production. For instance, we can use the hanging protocol module to inject a hanging protocol into the core and later use it to test the hanging protocol detection mechanism.