- Shipped
- September 9, 2026 at 10:22 PM UTC
- Author
- Kamo
- Commit
- c0977ae
The publish steps sat inside `build`, so run 12014 failed and took the image with it — and `pnpm install --frozen-lockfile` was clean locally, which is the tell: what failed was the runner setup, not the workspace. It is a job of its own now, `build` does not wait for it, and it pins node 22 to match kamo-js, the other repo that publishes @kamo/* from these same runners. A registry that is down must not stop this app shipping, and when publishing does fail it should fail on a row that says "publish", not inside a docker build where it reads as a build error. An absent NPM_PUBLISH_TOKEN now fails with a message naming itself rather than writing an empty auth line and getting a 401 from `pnpm publish` three steps later. `pdfjs-dist` is a PEER dependency of @kamo/doc-render, pinned exact, not a dependency. As a dependency npm is free to install a second nested copy in the consumer — and both apps SELF-HOST the pdf.js worker, copying `pdf.worker.min.mjs` out of their own pdfjs-dist at build time. A nested 4.10.38 beside a hoisted 4.11 would hand that worker to an engine it does not match, and the failure surfaces as a document that will not render on a page somebody is being asked to sign. There is already one version skew in this area to be careful of: kamo-internal's PdfCanvas loads pdf.js 4.4.168 from cdnjs into `window.pdfjsLib`, a different engine that stays uncorrupted only because the two module instances never meet.