La idea clave
El token separa preparación y publicación, pero conserva otros permisos de escritura.
Una automatización puede construir un paquete correctamente y aun así publicar algo que nadie quería distribuir. El 18 de septiembre, GitHub anunció un permiso granular de npm, Read and write (stage only), para separar la preparación de una versión de su publicación definitiva.
Según el anuncio oficial, el flujo envía la versión con npm stage publish. Un mantenedor la revisa y aprueba con autenticación de dos factores. El registro rechaza un intento de npm publish directo con ese token, incluso si tiene configurada la excepción de 2FA para automatización.
Qué es nuevo y qué no cambia automáticamente
La novedad es el permiso del token; la publicación por etapas ya estaba documentada. Su adopción es opcional y no transforma las credenciales existentes. Además, estos tokens conservan otras operaciones de escritura, como mover etiquetas de distribución y marcar versiones como obsoletas.
Por tanto, no basta con llamarlo «token de revisión» para considerar que cualquier uso es inocuo. Delimita qué paquetes necesita manejar tu flujo y qué operaciones realiza realmente.
Requisitos y recorrido de una versión
La documentación de publicación por etapas exige un paquete ya existente, permisos para publicarlo, 2FA en la cuenta, npm CLI 11.15.0 o posterior y Node.js 22.14.0 o posterior. Este mecanismo no sirve para estrenar un paquete inexistente en el registro.
Una versión enviada se puede inspeccionar desde la CLI o la pestaña Staged Packages de npmjs.com. El proceso permite consultar sus detalles y descargar el archivo del paquete antes de aprobarlo. La aprobación lo publica y requiere 2FA.
Comprueba esos requisitos en el entorno que construye el paquete, no solo en tu portátil. Una versión distinta de la herramienta dentro de la automatización puede explicar que un comando disponible localmente falle en el proceso remoto.
La revisión debe mirar lo que recibirán los usuarios
Ejemplo propuesto por Texploto
Un agente ayuda a actualizar una biblioteca. Las pruebas del repositorio pasan, pero el empaquetado omite un archivo que la aplicación necesita al arrancar. El cambio de código parece correcto y el paquete final está incompleto.
Una revisión útil comprobaría el contenido distribuido y probaría su instalación en un proyecto de ejemplo. También revisaría nombre, versión y cambios de dependencias. La aprobación no debería reducirse a reconocer el nombre de una ejecución que terminó en verde.
Conserva una referencia clara a la revisión de código que originó el paquete. Si hay varias versiones pendientes, evita decidir por el orden en que aparecen: identifica exactamente cuál estás aprobando y qué comprobaciones corresponden a ella.
Cómo organizar el cambio en un proyecto pequeño
Empieza por describir el proceso actual: quién construye, dónde se guarda la credencial y quién decide publicar. Después introduce la etapa de revisión con una persona responsable y un criterio de aceptación concreto.
Prepara también el caso de rechazo. Si el paquete está mal, documenta qué faltó y vuelve a generar la versión adecuada antes de aprobar. Automatizar los pasos repetitivos tiene más valor cuando el resultado que espera la persona revisora está bien definido.
Nuestra explicación de AI Scan en pull requests trata una comprobación anterior. Revisar código y revisar el paquete que sale de ese código cubren momentos diferentes; una no demuestra por sí sola que la otra esté resuelta.
Fuentes consultadas el 19/09/2026. No hemos creado credenciales ni ejecutado una publicación npm para este artículo.
