- Shipped
- 9 de septiembre de 2026 a las 22:22 UTC
- Author
- Kamo
- Commit
- c0977ae
Los pasos de publicación se pusieron dentro de la página de "Build", así que ejecutar 12014 falló y tomó la imagen con ella y Instalación de "pnpm" --froz-lockfile" estaba limpio localmente, que es el saber: lo que falló fue el corredor configuración, no el espacio de trabajo. Ahora es un trabajo propio, "Build" no lo espera, y pincha. nodo 22 para que coinzca con kamo-js, el otro repo que publica .kamo/* de estos mismos corredores. Un registro que está abajo no debe detener este envío de aplicaciones, y cuando la edición falla debe fallar en una fila que dice "publicar", no dentro de una construcción de ateo donde se lee como un error de construcción. Un NPM-PUBLISH-TOKEN ausente falla ahora con un mensaje que se nombra a sí mismo en lugar de escribir un vacío Línea de auth y conseguir un 401 de la publicación de 3 pasos más tarde. La dependencia de PEER es una dependencia de PEER de "kamo/doc-render", llame exacta, no de dependencia. Como a la dependencia npm es libre de instalar una segunda copia anidada en el consumidor y ambas aplicaciones SELF-HOST el trabajador de pdf.js, copiando "pdf.worker.min.mjs" de su propio pdfjs-dist en el tiempo de construcción. Un anidado 4.10.38 junto a un izado 4.11 entregaría a ese trabajador a un motor que no coincide, y El fallo aparece como un documento que no entregará en una página que se le pide a alguien que firme. Ya hay una versión sesgada en esta zona a la que tener cuidado: las cargas PdfCanvas de kamo-internal pdf.js 4.4.168 de cdnjs en .window.pdfjsLib, un motor diferente que permanece incorrupto solamente porque las dos instancias del módulo nunca se cumplen.