Lad npm vælge registret efter pakkens omfang, ikke efter VPN

At forbinde VPN’en bør ikke betyde, at man redigerer npms registerindstilling to gange om dagen. En omfangspost i en projektniveau-konfigurationsfil kan sende virksomhedens pakker til ét register og alt andet til det offentlige, uden skift og uden en tilsidesættelse, der bliver efterladt en fredag eftermiddag. Haken er, at dette kun løser navngivningen; routing, legitimationsoplysninger og konfigurationsforrang er tre separate ting, som hver især fejler på sin egen måde.

To navne, to destinationer

Et npm-pakkenavn har enten et omfang eller ikke. Et navn med omfang begynder med et at-tegn og en omfangsidentifikator, og det er den identifikator, konfigurationen kan mappe. Intet andet ved pakken betyder noget for mappingen. Registret ser aldrig en anmodning baseret på, om pakken er intern eller offentlig; det ser kun et navn.

Så filen nedenfor udtrykker to hensigter på tre linjer: offentlige pakker går til det offentlige register, og pakker under virksomhedens omfang går til virksomhedens register med et token til den vært.

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

Erstat omfanget, værten og variabelnavnet med det, organisationen faktisk stiller til rådighed. Strukturen er det vigtige, ikke eksempelværdierne. To linjer konfiguration bærer hele politikken, og derfor er de værd at forstå i stedet for at kopiere.

Hold mappingen og netværket i adskilte rum i hovedet. En omfangspost kan ikke gøre en utilgængelig vært tilgængelig, og en fungerende tunnel kan ikke fortælle npm, hvilket register en pakke hører til.

Skriv filen i den rigtige rækkefølge

Sæt projektfilen først i din ræsonnering, selvom npm læser flere filer. En .npmrc i projektmappen er den, dine kolleger arver gennem repositoryet, så den bør udtrykke den fælles politik frem for dit personlige token. Den fil er også den, en anmelder vil læse. Hold den lille nok til at kunne gennemses med et blik.

Lad standardlinjen registry pege på det offentlige register, medmindre organisationen har besluttet andet. Fjerner man den, afhænger maskinen af, hvad filen på brugerniveau siger, og det er netop den slags implicitte afhængighed, der giver forskellige resultater på to laptops.

Omfangslinjen er ikke et jokertegn. Et navn uden for omfanget bruger fortsat standarden, og det er den adfærd, du ønsker for enhver afhængighed, du ikke selv har skrevet.

Kontroller, hvad filen opløses til, før du committer den, ved at bruge et engangspakkenavn i stedet for en rigtig installation, så en fejl ikke koster noget.

Legitimationsoplysninger hører til en vært, ikke et projekt

Godkendelsesposter er knyttet til en registervært og, hvor registret har brug for det, en sti. Derfor begynder tokenlinjen med den dobbelte skråstreg og værten i stedet for omfanget. Når du først ser værten på den plads, holder resten af linjen op med at se ud som vilkårlig tegnsætning. Det er en adresse, og tokenet er knyttet til den.

At bruge en miljøvariabel holder det bogstavelige token ude af filen i repositoryet. Det gør ikke tokenet usynligt overalt; det optræder stadig i procesmiljøet, og en kommando, der udskriver konfiguration, kan afsløre det.

Skaf variablen gennem den lokale eller CI-legitimationsmekanisme, som organisationen godkender, og indsæt aldrig et rigtigt token i et eksempel, der kan blive kopieret til dokumentationen.

Hvis to registre er i spil, får hvert sit eget opslag. En enkelt ukvalificeret tokenindstilling er i bedste fald tvetydig og i værste fald sendt til den forkerte vært.

Når det forkerte register vinder

Konfiguration er lagdelt, og den gældende værdi er ikke nødvendigvis værdien i den fil, du netop har redigeret. Projektindstillinger, brugerindstillinger, globale indstillinger og miljøvariabler deltager alle. Den lagdeling er grunden til, at en rettelse virker på din maskine og ikke i en kollegas container. Det er også grunden til, at den effektive værdi er værd at udskrive, før du diskuterer den.

Miljøvariablen er den sædvanlige synder i CI, hvor et job sætter registret én gang, og hvert efterfølgende trin arver det. Den næstmest almindelige er en fil på brugerniveau på en udviklers maskine, som tilsidesætter det, repositoryet siger.

Udskriv den effektive konfiguration og det opløste register for ét navn med omfang og ét uden omfang, før du fejlretter noget andet. Hvis de to svar er, hvad du forventer, er problemet netværket; hvis ikke, er problemet konfiguration, og intet VPN-arbejde vil hjælpe.

Tjekliste før du committer

Bekræft, at omfangsnavnet matcher de pakker, der faktisk er udgivet, at standardregistret er eksplicit, og at tokenlinjen angiver den korrekte vært. En tastefejl i omfanget giver den mærkeligste fejl af alle, fordi pakken opløses fra det offentlige register og returnerer en andens modul med samme navn. Kontroller navnet, før du fejlretter tokenet.

Bekræft, at det private register kan nås fra maskinen i den kontekst, der kører installationen, ikke blot fra din browser. Den forskel betyder noget, når en proxy eller en container har en anden routing end din shell.

Bekræft derefter adfærden på et rent checkout uden cachede pakker. En frisk installation er den eneste test, der viser, hvad en ny kollega vil opleve.