Deje que npm elija el registro por ámbito del paquete, no por la VPN

Conectar la VPN no debería significar editar el ajuste de registro de npm dos veces al día. Una entrada de ámbito en un archivo de configuración a nivel de proyecto puede enviar los paquetes de la empresa a un registro y todo lo demás al público, sin conmutaciones y sin una anulación olvidada un viernes por la tarde. El problema es que esto solo resuelve la nomenclatura; el enrutamiento, las credenciales y la precedencia de configuración son tres cosas separadas que fallan cada una a su manera.

Dos nombres, dos destinos

Un nombre de paquete de npm o tiene un ámbito o no lo tiene. Un nombre con ámbito empieza por un signo @ y un identificador de ámbito, y ese identificador es lo que la configuración puede asignar. Nada más del paquete importa para la asignación. El registro nunca ve una petición basada en si el paquete es interno o público; solo ve un nombre.

Así, el archivo de abajo expresa dos intenciones en tres líneas: los paquetes públicos van al registro público, y los paquetes bajo el ámbito de la empresa van al registro de la empresa con un token para ese host.

registry=https://registry.npmjs.org/
@acme:registry=https://packages.corp.example/
//packages.corp.example/:_authToken=${NPM_TOKEN}

Sustituya el ámbito, el host y el nombre de la variable por lo que la organización proporcione realmente. La estructura es lo que importa, no los valores de ejemplo. Dos líneas de configuración llevan toda la política, por eso vale la pena entenderlas en lugar de copiarlas.

Mantenga la asignación y la red en compartimentos separados en su cabeza. Una entrada de ámbito no puede hacer accesible un host inaccesible, y un túnel que funciona no puede decirle a npm a qué registro pertenece un paquete.

Escriba el archivo en el orden correcto

Ponga el archivo del proyecto primero en su razonamiento aunque npm lea varios archivos. Un .npmrc en el directorio del proyecto es el que sus colegas heredan a través del repositorio, así que debería expresar la política compartida y no su token personal. Ese archivo es también el que leerá un revisor. Manténgalo lo bastante pequeño para revisarlo de un vistazo.

Deje la línea registry predeterminada apuntando al registro público salvo que la organización haya decidido lo contrario. Quitarla hace que la máquina dependa de lo que diga el archivo de nivel de usuario, y esa es exactamente la clase de dependencia implícita que produce resultados distintos en dos portátiles.

La línea de ámbito no es un comodín. Un nombre fuera del ámbito sigue usando el valor predeterminado, y ese es el comportamiento que quiere para cada dependencia que no haya escrito usted mismo.

Compruebe a qué resuelve el archivo antes de confirmarlo, usando un nombre de paquete desechable en lugar de una instalación real, para que un error no cueste nada.

Las credenciales pertenecen a un host, no a un proyecto

Las entradas de autenticación están vinculadas a un host de registro y, donde el registro lo necesita, a una ruta. Por eso la línea del token empieza por la doble barra y el host en lugar del ámbito. En cuanto vea el host en esa posición, el resto de la línea deja de parecer puntuación arbitraria. Es una dirección, y el token está unido a ella.

Usar una variable de entorno mantiene el token literal fuera del archivo en el repositorio. No hace que el token sea invisible en todas partes; sigue apareciendo en el entorno del proceso, y un comando que imprima la configuración puede revelarlo.

Proporcione la variable mediante el mecanismo local o de credenciales de CI que apruebe la organización, y nunca pegue un token real en un ejemplo que pueda copiarse a la documentación.

Si hay dos registros en juego, cada uno recibe su propia entrada. Una única configuración de token no cualificada es como mínimo ambigua y como máximo enviada al host equivocado.

Cuando gana el registro equivocado

La configuración está por capas, y el valor efectivo no es necesariamente el valor del archivo que acaba de editar. La configuración del proyecto, la del usuario, la global y las variables de entorno participan todas. Esa estratificación es la razón por la que una corrección funciona en su máquina y no en el contenedor de un colega. También es la razón por la que vale la pena imprimir el valor efectivo antes de discutir sobre él.

La variable de entorno es el culpable habitual en CI, donde una tarea fija el registro una vez y cada paso posterior lo hereda. El segundo más común es un archivo de nivel de usuario en la máquina de un desarrollador que anula lo que dice el repositorio.

Imprima la configuración efectiva y el registro resuelto para un nombre con ámbito y otro sin ámbito antes de depurar cualquier otra cosa. Si esas dos respuestas son lo que espera, el problema es la red; si no lo son, el problema es la configuración y ninguna cantidad de trabajo con la VPN ayudará.

Lista de comprobación antes de confirmar

Confirme que el nombre de ámbito coincide con los paquetes realmente publicados, que el registro predeterminado es explícito y que la línea del token nombra el host correcto. Una errata en el ámbito produce el fallo más extraño de todos, porque el paquete se resuelve desde el registro público y devuelve el módulo de otra persona con el mismo nombre. Compruebe el nombre antes de depurar el token.

Confirme que el registro privado es accesible desde la máquina en el contexto que ejecuta la instalación, no solo desde su navegador. Esa distinción importa cuando un proxy o un contenedor tiene un enrutamiento distinto al de su shell.

Luego confirme el comportamiento en un checkout limpio sin paquetes en caché. Una instalación nueva es la única prueba que muestra lo que experimentará un colega nuevo.