Lăsați npm să aleagă registrul după domeniul pachetului, nu după VPN

Conectarea la VPN nu ar trebui să însemne editarea setării de registru a npm de două ori pe zi. O intrare de domeniu într-un fișier de configurare la nivel de proiect poate trimite pachetele companiei către un registru și restul către cel public, fără comutări și fără o suprascriere uitată într-o vineri după-amiază. Problema este că acest lucru rezolvă doar denumirea; rutarea, acreditările și precedența configurației sunt trei lucruri separate care eșuează fiecare în felul său.

Două nume, două destinații

Un nume de pachet npm fie are un domeniu, fie nu are. Un nume cu domeniu începe cu semnul @ și un identificator de domeniu, iar acel identificator este ceea ce configurația poate mapa. Nimic altceva la pachet nu contează pentru mapare. Registrul nu vede niciodată o cerere bazată pe faptul că pachetul este intern sau public; vede doar un nume.

Așadar fișierul de mai jos exprimă două intenții în trei linii: pachetele publice merg la registrul public, iar pachetele din domeniul companiei merg la registrul companiei cu un token pentru acea gazdă.

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

Înlocuiți domeniul, gazda și numele variabilei cu ceea ce organizația oferă de fapt. Structura este cea care contează, nu valorile exemplu. Două linii de configurare poartă întreaga politică, de aceea merită înțelese în loc de copiate.

Țineți maparea și rețeaua în compartimente separate în minte. O intrare de domeniu nu poate face accesibilă o gazdă inaccesibilă, iar un tunel funcțional nu poate spune npm cărei registre aparține un pachet.

Scrieți fișierul în ordinea corectă

Puneți fișierul proiectului pe primul loc în raționamentul dumneavoastră, deși npm citește mai multe fișiere. Un .npmrc din directorul proiectului este cel pe care colegii îl moștenesc prin depozit, așa că ar trebui să exprime politica comună și nu tokenul personal. Acel fișier este și cel pe care îl va citi un recenzent. Țineți-l suficient de mic pentru a fi revizuit dintr-o privire.

Lăsați linia registry implicită să indice registrul public, dacă organizația nu a decis altfel. Eliminarea ei face mașina dependentă de ce spune fișierul la nivel de utilizator, iar acesta este exact tipul de dependență implicită care produce rezultate diferite pe două laptopuri.

Linia de domeniu nu este un metacaracter. Un nume din afara domeniului continuă să folosească valoarea implicită, iar acesta este comportamentul pe care îl doriți pentru fiecare dependență pe care nu ați scris-o dumneavoastră.

Verificați la ce se rezolvă fișierul înainte de a-l confirma, folosind un nume de pachet de unică folosință în locul unei instalări reale, ca o greșeală să nu coste nimic.

Acreditările aparțin unei gazde, nu unui proiect

Intrările de autentificare sunt legate de o gazdă de registru și, unde registrul are nevoie, de o cale. De aceea linia tokenului începe cu bara dublă și gazda, nu cu domeniul. Odată ce vedeți gazda în acea poziție, restul liniei nu mai arată ca punctuație arbitrară. Este o adresă, iar tokenul este atașat de ea.

Folosirea unei variabile de mediu ține tokenul literal în afara fișierului din depozit. Nu face tokenul invizibil peste tot; el apare în continuare în mediul procesului, iar o comandă care afișează configurația îl poate dezvălui.

Furnizați variabila prin orice mecanism local sau de acreditări CI pe care organizația îl aprobă, și nu lipiți niciodată un token real într-un exemplu care ar putea fi copiat în documentație.

Dacă sunt implicate două registre, fiecare primește propria intrare. O singură setare de token necalificată este cel mai bine ambiguă și cel mai rău trimisă către gazda greșită.

Când câștigă registrul greșit

Configurația este stratificată, iar valoarea în vigoare nu este neapărat valoarea din fișierul pe care tocmai l-ați editat. Setările proiectului, setările utilizatorului, setările globale și variabilele de mediu participă toate. Această stratificare este motivul pentru care o corecție funcționează pe mașina dumneavoastră și nu în containerul unui coleg. Este și motivul pentru care merită să tipăriți valoarea efectivă înainte de a discuta despre ea.

Variabila de mediu este vinovatul obișnuit în CI, unde un job setează registrul o dată și fiecare pas ulterior îl moștenește. Al doilea cel mai frecvent este un fișier la nivel de utilizator pe mașina unui dezvoltator care suprascrie ce spune depozitul.

Tipăriți configurația efectivă și registrul rezolvat pentru un nume cu domeniu și unul fără domeniu înainte de a depana orice altceva. Dacă aceste două răspunsuri sunt ceea ce așteptați, problema este rețeaua; dacă nu sunt, problema este configurația și nicio muncă la VPN nu va ajuta.

Listă de verificare înainte de confirmare

Confirmați că numele domeniului corespunde pachetelor publicate efectiv, că registrul implicit este explicit și că linia tokenului numește gazda corectă. O greșeală de tipar în domeniu produce cea mai stranie defecțiune dintre toate, pentru că pachetul se rezolvă din registrul public și returnează modulul altcuiva cu același nume. Verificați numele înainte de a depana tokenul.

Confirmați că registrul privat este accesibil de pe mașina din contextul care rulează instalarea, nu doar din browserul dumneavoastră. Această distincție contează când un proxy sau un container are o rutare diferită de shell-ul dumneavoastră.

Apoi confirmați comportamentul pe un checkout curat, fără pachete din cache. O instalare proaspătă este singurul test care arată ce va experimenta un coleg nou.