Su equipo quiere publicar su primera biblioteca de JavaScript desde su canalización automatizada. ¿Quién crea el paquete, quién examina su contenido y cuándo se valida la identidad de la canalización? Ambos cambios de npm anunciados el 2 de octubre de 2026 hacen que esta secuencia sea más importante. Un paquete listo para ser examinado y una configuración de confianza válida son dos estados diferentes.
El primer paquete añade un paso al lanzamiento
Nuestro artículo del 1 de octubre sobre los pasos y permisos de publicación npm detalla la separación de los derechos; éste examina los nuevos paquetes y el ciclo de validación de confianza anunciado el 2 de octubre.
Tomemos una biblioteca ficticia, reservada para nuestro escenario. Su archivo contiene el código destinado a otras aplicaciones. El pipeline prepara este archivo, pero una persona debe poder examinarlo antes de que se distribuya una versión utilizable. La cuestión no es solo «¿puede la automatización publicar?»: también hay que saber qué puede preparar y quién decide su puesta a disposición.
El 2 de octubre, npm anunció la posibilidad de crear un nuevo paquete con npm stage publish, desde una sesión local o un token granular, incluyendo un token limitado a la preparación. La versión enviada entra en una cola de revisión y debe ser promovida por un mantenedor antes de convertirse en instalable. La configuración del paquete y de la publicación confiable luego puede organizarse. Anuncio sobre los nuevos paquetes.
La publicación en etapa se refiere a esta publicación en espera de aprobación. La publicación confiable es un mecanismo separado: permite a un entorno automatizado identificado actuar sobre el paquete. Por lo tanto, puede tener un archivo en espera y una confianza no validada, o una confianza válida con un archivo aún no aprobado. El artículo examina estos estados, en lugar de reunir todo el lanzamiento bajo un botón «publicar».
El cambio de las 48 horas concierne a la confianza no validada
El otro anuncio del 2 de octubre se refiere a las configuraciones de publicación confiable no validadas. Expiran 48 horas después de su creación. Una primera publicación exitosa las valida y las exime de esta expiración. Un cambio de identidad del repositorio o del proyecto requiere una nueva relación de confianza; una modificación ordinaria no reinicia el contador. Las configuraciones expiradas siguen siendo visibles y deben ser recreadas para abrir una nueva ventana. Anuncio de npm sobre la expiración.
El mismo anuncio precisa la negativa de los tokens provenientes de eventos GitHub Actions issue_comment, además de la restricción ya aplicada a pull_request_target. Un disparador de flujo de trabajo describe la situación en la que se inicia el pipeline. Aquí, un contexto rechazado no se convierte en autorizado porque su archivo ha sido aprobado. Restricción de los contextos de publicación.
No convierta las 48 horas en la duración de todos sus secretos ni en un plazo universal para la promoción de una versión. Esta ventana se refiere a un estado preciso de la configuración. El escenario exacto que valida la confianza debe observarse en su proceso: la sola presencia de un archivo en espera no es suficiente para demostrarlo.
Dibujar el recorrido antes de lanzar la automatización
Escriba una ficha con el nombre del paquete, su responsable, el repositorio esperado y la versión inicial. Añada el componente que produce el archivo, la persona que lo examina y la que puede promocionarlo. Una misma persona puede desempeñar varios roles, pero estas decisiones deben seguir siendo identificables.
La documentación de npm consultada el 6 de octubre describe una versión de espera 0.0.0-stage creada cuando un paquete aún no existe. Este marcador de posición es público; la versión enviada y su contenido permanecen en espera hasta la aprobación. Por lo tanto, el staging tiene un efecto visible en el registro antes de la distribución de su archivo real. La documentación también indica npm CLI 11.15.0 o superior y Node 22.14.0 o superior. Documentación de publicación por etapas.
Para nuestra biblioteca ficticia, la primera verificación consiste en comparar el archivo con lo que debía entregarse. Examine los archivos incluidos, las dependencias y los scripts que puedan ejecutarse durante la instalación. Haga esto en un entorno aislado adecuado para su proyecto. El hecho de que un archivo provenga de un pipeline conocido no establece que su contenido corresponda a la solicitud.
Luego documente el paso entre preparación y promoción. La persona que aprueba debe saber qué archivo ha sido examinado y a qué versión corresponde. Una prueba de revisión de otro archivo, incluso si tiene un nombre similar, no es una prueba para este artefacto. Su seguimiento puede usar una huella del archivo en los rastros privados, sin saturar el mensaje destinado a los usuarios.
Seguir los dos ciclos de vida
La tabla a continuación es un método de seguimiento propuesto, basado en los estados de confianza anunciados. No describe una interfaz npm inventada.
| Estado de la confianza | Significado a verificar | Acción del equipo |
|---|---|---|
| No validada | Primera publicación exitosa aún no constatada | Preparar la validación en la ventana prevista |
| Validada | Primera publicación exitosa observada | Vigilar la identidad y los permisos |
| Caducada | Ventana de validación completada | Recrear la relación después de examinar el motivo |
| Identidad cambiada | Repositorio o proyecto diferente | Examinar y establecer la nueva relación |
Al lado, mantenga un seguimiento independiente del archivo: preparado, examinado, aprobado y luego distribuido. La expiración de una confianza no prueba que se haya retirado una versión. La aprobación de un archivo no prueba que otro pipeline esté autorizado. Al separar estos estados, puede identificar al responsable correcto cuando una operación falla.
Para el mecanismo de identidad, explique al equipo qué significa OpenID Connect, a menudo abreviado OIDC: el pipeline presenta una prueba vinculada a su contexto de ejecución, en lugar de un simple secreto permanente copiado en todas partes. La decisión útil sigue siendo la identidad efectivamente admitida. Una etiqueta OIDC en una configuración no reemplaza la revisión del repositorio, del flujo de trabajo y del disparador.
Agregue una alerta operativa adecuada al lanzamiento: ¿quién nota una configuración aún no validada, dónde se registra la fecha de creación y quién decide una recreación? No recree automáticamente las relaciones sin entender por qué expiran. De lo contrario, una dificultad de coordinación entre preparación, revisión y lanzamiento podría permanecer invisible.
Probar los rechazos con un modelo local
Antes de cualquier acción sobre un registro, puede construir una simulación local de los estados. Recibe una configuración ficticia, una fecha de creación y un resultado de publicación ficticio. Calcula si la relación no está validada, está validada o ha expirado según su modelo del anuncio. Los horarios son entradas de prueba, no observaciones sobre npm.
Prepare cuatro casos: relación no validada en la ventana, relación no validada después de la expiración, relación validada e identidad modificada. Para cada caso, indique la transición esperada y la decisión que deberá tomar un responsable. Esta simulación prueba su comprensión y su procedimiento; no califica por sí sola el comportamiento del registro.
Agregue rechazos relacionados con el archivo: contenido ausente, versión revisada diferente de la versión propuesta, aprobación faltante. También agregue un contexto de ejecución prohibido. El mensaje obtenido debe indicar qué dimensión está en cuestión, sin mostrar una prueba de identidad o un secreto. La respuesta apropiada a un archivo no revisado no es modificar la confianza del flujo de trabajo.
Para un ensayo posterior autorizado en un registro, verifique primero el espacio de nombres, los propietarios y los efectos de creación pública. Los comandos citados en este artículo sirven para identificar los mecanismos; no se ha creado ningún paquete ni se ha ejecutado ningún comando de preparación, publicación o promoción para producir este contenido.
Prever una reanudación comprensible
Si la ventana expira, comience por la cronología: ¿cuándo se creó la relación, qué evento debía validarla y qué observación falta? Verifique si el pipeline realmente alcanzó la etapa de publicación, si su identidad coincide y si el contexto está permitido. La recreación se realiza después de esta revisión, con el responsable de lanzamiento.
Si el archivo sigue pendiente, busque del lado del examen y la aprobación. No fuerce una publicación directa solo para desbloquear un calendario. El procedimiento debe especificar quién puede decidir abandonar una versión, corregir el archivo o retomar la secuencia. Así se preserva la utilidad de la separación de roles.
Para su primer paquete, tenga en cuenta cinco criterios: artefacto inspeccionado, identidad revisada, validación efectivamente observada, derecho de promoción atribuido y procedimiento de caducidad documentado. Esta cuadrícula no mide ninguna ganancia de seguridad global; ofrece decisiones concretas que verificar. Cuando falte un criterio, termine la preparación correspondiente antes de ampliar el pipeline a las versiones siguientes.
El lanzamiento se vuelve más fácil de explicar cuando cada uno sabe distinguir «paquete creado», «contenido aprobado» y «confianza validada». Los anuncios del 2 de octubre modifican estos pasos, pero su regla de equipo mantiene la secuencia. Primero trate de recorrerla con datos ficticios y rechazos previstos: luego sabrá qué pruebas recopilar en un ensayo real autorizado.
Fuentes y fecha de verificación
Fuentes abiertas el 6 de octubre de 2026: vencimiento de la confianza, creación de un nuevo paquete en staging y documentación npm. Ambos anuncios datan del 2 de octubre; la documentación viva proporciona contexto. Se proponen el escenario y la simulación, sin publicación real ni resultado reclamado.