- Navios
- 9 de setembro de 2026 às 22:22 UTC
- Autor
- Kamo
- Enviar
- c0977ae
As etapas de publicação se sentaram dentro de `build`, então a execução 12014 falhou e levou a imagem com ele — e `pnpm install --congeled-lockfile` estava limpo localmente, que é a indicação: o que falhou foi o corredor configuração, não o espaço de trabalho. É um trabalho próprio agora, 'construir' não espera por ele, e ele alfineta node 22 para corresponder kamo-js, o outro repo que publica @kamo/* a partir destes mesmos corredores. Um registo que está para baixo não deve parar este envio app, e quando a publicação falha deve falhar em uma linha que diz "publicar", não dentro de um docker construir onde ele lê como um erro de construção. Um NPM PUBLISH TOKEN ausente agora falha com um nome de mensagem em vez de escrever um vazio linha de autenticação e obter um 401 de `pnpm publique` três passos mais tarde. `pdfjs-dist` é uma dependência PEER de @kamo/doc-render, fixada exata, não uma dependência. Como uma dependência npm é livre para instalar uma segunda cópia aninhada no consumidor — e ambos os aplicativos SELF-HOST o pdf.js worker, copiando `pdf.worker.min.mjs` de seu próprio pdfjs-dist em tempo de construção. Um ninho 4.10.38 ao lado de um elevador 4.11 entregaria aquele trabalhador a um motor que não corresponde, e o o erro aparece como um documento que não irá renderizar em uma página que alguém está sendo solicitado a assinar. Já existe uma versão distorcida nesta área para ter cuidado: cargas PdfCanvas do kamo-internal pdf.js 4.4.168 de cdnjs para `window.pdfjsLib`, um motor diferente que permanece incorrupto apenas porque as duas instâncias do módulo nunca se encontram.