Deixeu que npm triï el registre per abast del paquet, no per la VPN

Connectar la VPN no hauria de significar editar la configuració del registre d’npm dues vegades al dia. Una entrada d’abast en un fitxer de configuració a nivell de projecte pot enviar els paquets de l’empresa a un registre i tota la resta al públic, sense commutacions i sense cap substitució que quedi oblidada un divendres a la tarda. L’escull és que això només resol el nomenclàtor; l’encaminament, les credencials i la precedència de configuració són tres coses separades que fallen cadascuna a la seva manera.

Dos noms, dues destinacions

Un nom de paquet npm o té un abast o no en té. Un nom amb abast comença amb un signe @ i un identificador d’abast, i és aquest identificador el que la configuració pot assignar. Cap altra cosa del paquet no importa per a l’assignació. El registre no veu mai una petició basada en si el paquet és intern o públic; només veu un nom.

Així, el fitxer de sota expressa dues intencions en tres línies: els paquets públics van al registre públic, i els paquets sota l’abast de l’empresa van al registre de l’empresa amb un testimoni per a aquell amfitrió.

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

Substituïu l’abast, l’amfitrió i el nom de la variable pel que l’organització proporcioni realment. L’estructura és el que importa, no els valors d’exemple. Dues línies de configuració porten tota la política, i per això val la pena entendre-les en lloc de copiar-les.

Manteniu l’assignació i la xarxa en compartiments separats al cap. Una entrada d’abast no pot fer accessible un amfitrió inaccessible, i un túnel que funciona no pot dir a npm a quin registre pertany un paquet.

Escriviu el fitxer en l’ordre correcte

Poseu el fitxer del projecte primer en el vostre raonament encara que npm llegeixi diversos fitxers. Un .npmrc al directori del projecte és el que els vostres col·legues hereten a través del repositori, així que hauria d’expressar la política compartida i no el vostre testimoni personal. Aquest fitxer també és el que llegirà un revisor. Manteniu-lo prou petit per revisar-lo d’una ullada.

Deixeu la línia registry per defecte apuntant al registre públic tret que l’organització hagi decidit el contrari. Treure-la fa que la màquina depengui del que digui el fitxer d’usuari, i aquesta és exactament la mena de dependència implícita que produeix resultats diferents en dos portàtils.

La línia d’abast no és un comodí. Un nom fora de l’abast continua usant el valor per defecte, i aquest és el comportament que voleu per a cada dependència que no heu escrit vosaltres.

Comproveu a què es resol el fitxer abans de cometre’l, amb un nom de paquet d’un sol ús en lloc d’una instal·lació real, perquè un error no costi res.

Les credencials pertanyen a un amfitrió, no a un projecte

Les entrades d’autenticació estan indexades per un amfitrió de registre i, on el registre ho necessita, per un camí. Per això la línia del testimoni comença amb la doble barra i l’amfitrió en lloc de l’abast. Un cop veieu l’amfitrió en aquesta posició, la resta de la línia deixa de semblar puntuació arbitrària. És una adreça, i el testimoni hi va adjunt.

Usar una variable d’entorn manté el testimoni literal fora del fitxer del repositori. No fa el testimoni invisible a tot arreu; encara apareix a l’entorn del procés, i una ordre que imprimeixi la configuració pot revelar-lo.

Proveïu la variable a través de qualsevol mecanisme local o de credencials de CI que l’organització aprovi, i no enganxeu mai un testimoni real en un exemple que pugui ser copiat a la documentació.

Si hi ha dos registres en joc, cadascun rep la seva pròpia entrada. Una única configuració de testimoni no qualificada és com a mínim ambigua i com a màxim enviada a l’amfitrió equivocat.

Quan guanya el registre equivocat

La configuració és per capes, i el valor efectiu no és necessàriament el valor del fitxer que acabeu d’editar. La configuració del projecte, la de l’usuari, la global i les variables d’entorn hi participen totes. Aquesta capa és la raó per la qual una correcció funciona a la vostra màquina i no al contenidor d’un col·lega. També és la raó per la qual val la pena imprimir el valor efectiu abans de discutir-ne.

La variable d’entorn és el culpable habitual a CI, on una tasca fixa el registre una vegada i cada pas posterior l’hereta. El segon més comú és un fitxer d’usuari a la màquina d’un desenvolupador que substitueix el que diu el repositori.

Imprimiu la configuració efectiva i el registre resolt per a un nom amb abast i un sense abast abans de depurar res més. Si aquestes dues respostes són les que espereu, el problema és la xarxa; si no ho són, el problema és la configuració i cap quantitat de feina amb la VPN no ajudarà.

Llista de verificació abans de cometre

Confirmeu que el nom d’abast coincideix amb els paquets realment publicats, que el registre per defecte és explícit i que la línia del testimoni anomena l’amfitrió correcte. Una errata a l’abast produeix la fallada més estranya de totes, perquè el paquet es resol des del registre públic i retorna el mòdul d’algú altre amb el mateix nom. Comproveu el nom abans de depurar el testimoni.

Confirmeu que el registre privat és accessible des de la màquina en el context que executa la instal·lació, no només des del vostre navegador. Aquesta distinció importa quan un proxy o un contenidor té un encaminament diferent del vostre shell.

Després confirmeu el comportament en un checkout net sense paquets a la memòria cau. Una instal·lació nova és l’únic test que mostra què experimentarà un col·lega nou.