Deixe que npm escolla o rexistro polo ámbito do paquete, non pola VPN

Conectar a VPN non debería significar editar o axuste de rexistro de npm dúas veces ao día. Unha entrada de ámbito nun ficheiro de configuración a nivel de proxecto pode enviar os paquetes da empresa a un rexistro e todo o demais ao público, sen conmutacións e sen unha anulación esquecida un venres pola tarde. O problema é que isto só resolve a nomenclatura; o enrutamento, as credenciais e a precedencia de configuración son tres cousas separadas que fallan cada unha á súa maneira.

Dous nomes, dous destinos

Un nome de paquete de npm ou ten un ámbito ou non o ten. Un nome con ámbito comeza por un signo @ e un identificador de ámbito, e ese identificador é o que a configuración pode asignar. Nada máis do paquete importa para a asignación. O rexistro nunca ve unha petición baseada en se o paquete é interno ou público; só ve un nome.

Así, o ficheiro de abaixo expresa dúas intencións en tres liñas: os paquetes públicos van ao rexistro público, e os paquetes baixo o ámbito da empresa van ao rexistro da empresa cun token para ese host.

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

Substitúa o ámbito, o host e o nome da variable polo que a organización proporcione realmente. A estrutura é o que importa, non os valores de exemplo. Dúas liñas de configuración levan toda a política, por iso paga a pena entendelas en lugar de copialas.

Manteña a asignación e a rede en compartimentos separados na cabeza. Unha entrada de ámbito non pode facer accesible un host inaccesible, e un túnel que funciona non pode dicirlle a npm a que rexistro pertence un paquete.

Escriba o ficheiro na orde correcta

Pon o ficheiro do proxecto primeiro no teu razoamento aínda que npm lea varios ficheiros. Un .npmrc no directorio do proxecto é o que os teus colegas herdan a través do repositorio, así que debería expresar a política compartida e non o teu token persoal. Ese ficheiro é tamén o que lerá un revisor. Mantéñao o bastante pequeno para revisalo dunha ollada.

Deixa a liña registry predeterminada apuntando ao rexistro público salvo que a organización decidise o contrario. Quitala fai que a máquina dependa do que diga o ficheiro de nivel de usuario, e esa é exactamente a clase de dependencia implícita que produce resultados distintos en dous portátiles.

A liña de ámbito non é un comodín. Un nome fóra do ámbito segue usando o valor predeterminado, e ese é o comportamento que queres para cada dependencia que non escribiches ti mesmo.

Comproba a que resolve o ficheiro antes de confirmalo, usando un nome de paquete refugable en lugar dunha instalación real, para que un erro non custe nada.

As credenciais pertencen a un host, non a un proxecto

As entradas de autenticación están vinculadas a un host de rexistro e, onde o rexistro o necesita, a unha ruta. Por iso a liña do token comeza pola dobre barra e o host en lugar do ámbito. En canto vexas o host nesa posición, o resto da liña deixa de parecer puntuación arbitraria. É un enderezo, e o token está unido a el.

Usar unha variable de contorno mantén o token literal fóra do ficheiro no repositorio. Non fai que o token sexa invisible en todas partes; segue aparecendo no contorno do proceso, e un comando que imprima a configuración pode revelalo.

Proporciona a variable mediante o mecanismo local ou de credenciais de CI que aprobe a organización, e nunca pegues un token real nun exemplo que poida copiarse á documentación.

Se hai dous rexistros en xogo, cada un recibe a súa propia entrada. Unha única configuración de token non cualificada é como mínimo ambigua e como máximo enviada ao host equivocado.

Cando gaña o rexistro equivocado

A configuración está por capas, e o valor efectivo non é necesariamente o valor do ficheiro que acabas de editar. A configuración do proxecto, a do usuario, a global e as variables de contorno participan todas. Ese estratificado é a razón pola que unha corrección funciona na túa máquina e non no contedor dun colega. Tamén é a razón pola que paga a pena imprimir o valor efectivo antes de discutir sobre el.

A variable de contorno é o culpable habitual en CI, onde unha tarefa fixa o rexistro unha vez e cada paso posterior hérdano. O segundo máis común é un ficheiro de nivel de usuario na máquina dun desenvolvedor que anula o que di o repositorio.

Imprime a configuración efectiva e o rexistro resolto para un nome con ámbito e outro sen ámbito antes de depurar calquera outra cousa. Se esas dúas respostas son o que esperas, o problema é a rede; se non o son, o problema é a configuración e ningunha cantidade de traballo coa VPN axudará.

Lista de comprobación antes de confirmar

Confirma que o nome de ámbito coincide cos paquetes realmente publicados, que o rexistro predeterminado é explícito e que a liña do token nomea o host correcto. Un erro tipográfico no ámbito produce o fallo máis estraño de todos, porque o paquete resólvese desde o rexistro público e devolve o módulo doutra persoa co mesmo nome. Comproba o nome antes de depurar o token.

Confirma que o rexistro privado é accesible desde a máquina no contexto que executa a instalación, non só desde o teu navegador. Esa distinción importa cando un proxy ou un contedor ten un enrutamento distinto ao do teu shell.

Despois confirma o comportamento nun checkout limpo sen paquetes na caché. Unha instalación nova é a única proba que mostra o que experimentará un colega novo.