Local Development

Install

pnpm install

Common Commands

Release Gate

Before publishing packages or deploying production, run the focused checks for the area you changed. Renderer and asset changes should at least pass:

pnpm build-only
pnpm docs:build
pnpm verify:format-support
pnpm verify:renderer-assets
pnpm verify:smoke-matrix
pnpm verify:npm-install-smoke

Use pnpm verify:migration-gates for a broader migration gate.

Batch Release Safety

The private maintainer checkout builds and freezes the package artifacts once. Local packing uses four workers by default (FILE_VIEWER_PACK_CONCURRENCY); registry download and comparison use four (FILE_VIEWER_REGISTRY_CONCURRENCY). Both accept 1–8 workers. Reusing an already-built artifact is only valid when its source and dependency inputs are unchanged; it does not replace the frozen-release checks.

The GitHub npm workflow publishes the immutable Release tarballs with trusted publishing. It checks all package identities and integrity hashes before the first upload, then publishes in dependency layers, with up to three uploads and six registry checks at a time. A layer must become visible with matching integrity before dependent packages can start. Failures stop new work and wait for active operations to finish; rerunning the same Release skips only versions whose bytes already match. An authorization failure or registry delay is not a reason to allocate another version.

Compatibility aliases need their own version bump when their exact dependency changes. In particular, reusing an old msdoc-viewer version would keep those users on its old DOC renderer even after the other packages are updated. The version-freeze check rejects that plan. Registry verification, cold installs, production Demo checks and the final release postcheck are still required after publishing.