# Local Development (/guide/development)



## Install [#install]

```bash
pnpm install
```

## Common Commands [#common-commands]

| Command                       | Purpose                                                                                                  |
| ----------------------------- | -------------------------------------------------------------------------------------------------------- |
| `pnpm dev`                    | Run the main demo                                                                                        |
| `pnpm docs:dev`               | Run the documentation site                                                                               |
| `pnpm site:dev`               | Run the official site                                                                                    |
| `pnpm build-only`             | Build the main demo                                                                                      |
| `pnpm docs:build`             | Build documentation                                                                                      |
| `pnpm site:build`             | Build the official site                                                                                  |
| `pnpm verify:format-support`  | Verify 274 registered extensions (224 stable, 50 experimental) and 47 renderer pipelines stay documented |
| `pnpm verify:renderer-assets` | Verify runtime assets are included in renderer packages and web builds                                   |
| `pnpm verify:browser-smoke`   | Run demo and component browser smoke tests                                                               |

## Release Gate [#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:

```bash
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 [#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.