Låt npm välja register efter paketets scope, inte efter VPN:en

Att ansluta VPN:en borde inte innebära att man redigerar npms registerinställning två gånger om dagen. En scope-post i en konfigurationsfil på projektnivå kan skicka företagets paket till ett register och allt annat till det publika, utan omkoppling och utan en override som ligger kvar en fredagseftermiddag. Haken är att detta bara löser namngivningen; routning, autentiseringsuppgifter och konfigurationsprioritet är tre separata saker som var och en fallerar på sitt eget sätt.

Två namn, två destinationer

Ett npm-paketnamn har antingen ett scope eller inte. Ett namn med scope börjar med ett at-tecken och en scope-identifierare, och det är den identifieraren som konfigurationen kan mappa. Inget annat om paketet spelar roll för mappningen. Registret ser aldrig en förfrågan baserad på om paketet är internt eller publikt; det ser bara ett namn.

Filen nedan uttrycker alltså två avsikter på tre rader: publika paket går till det publika registret, och paket under företagets scope går till företagets register med en token för den värden.

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

Byt ut scopet, värden och variabelnamnet mot det organisationen faktiskt tillhandahåller. Det är strukturen som spelar roll, inte exempelvärdena. Två rader konfiguration bär hela policyn, vilket är varför de är värda att förstå i stället för att kopiera.

Håll mappningen och nätverket i separata fack i huvudet. En scope-post kan inte göra en onåbar värd nåbar, och en fungerande tunnel kan inte tala om för npm vilket register ett paket tillhör.

Skriv filen i rätt ordning

Sätt projektfilen först i ditt resonemang även om npm läser flera filer. En .npmrc i projektkatalogen är den som dina kollegor ärver via repositoryt, så den bör uttrycka den gemensamma policyn snarare än din personliga token. Den filen är också den som en granskare kommer att läsa. Håll den tillräckligt liten för att kunna granskas i ett svep.

Låt standardraden registry peka på det publika registret om inte organisationen har bestämt något annat. Att ta bort den gör maskinen beroende av vad användarnivåfilen säger, vilket är precis den sorts implicita beroende som ger olika resultat på två bärbara datorer.

Scope-raden är inte ett jokertecken. Ett namn utanför scopet fortsätter att använda standardvärdet, vilket är det beteende du vill ha för varje beroende du inte själv har skrivit.

Kontrollera vad filen löser upp till innan du commitar den, med ett tillfälligt paketnamn i stället för en riktig installation, så att ett misstag inte kostar något.

Autentiseringsuppgifter tillhör en värd, inte ett projekt

Autentiseringsposter är knutna till en registervärd och, där registret behöver det, en sökväg. Det är därför tokenraden börjar med det dubbla snedstrecket och värden i stället för scopet. När du väl ser värden på den platsen slutar resten av raden att se ut som godtycklig interpunktion. Det är en adress, och token är fäst vid den.

Att använda en miljövariabel håller den bokstavliga token utanför filen i repositoryt. Det gör inte token osynlig överallt; den finns fortfarande i processens miljö, och ett kommando som skriver ut konfigurationen kan avslöja den.

Tillhandahåll variabeln via vilken lokal eller CI-mekanism för autentiseringsuppgifter som organisationen godkänner, och klistra aldrig in en riktig token i ett exempel som kan kopieras till dokumentationen.

Om två register är inblandade får var och en sin egen post. En enda okvalificerad tokeninställning är i bästa fall tvetydig och i värsta fall skickad till fel värd.

När fel register vinner

Konfigurationen är skiktad, och det värde som gäller är inte nödvändigtvis värdet i filen du just redigerade. Projektinställningar, användarinställningar, globala inställningar och miljövariabler deltar alla. Det är därför en fix fungerar på din maskin men inte i en kollegas container. Det är också därför det effektiva värdet är värt att skriva ut innan du bråkar om det.

En miljövariabel är den vanliga boven i CI, där ett jobb ställer in ett register en gång och varje senare steg ärver det. Den näst vanligaste är en användarnivåfil på en utvecklares maskin som åsidosätter vad repositoryt säger.

Skriv ut den effektiva konfigurationen och det upplösta registret för ett namn med scope och ett utan innan du felsöker något annat. Om de två svaren är vad du förväntar dig är problemet nätverket; om de inte är det är problemet konfigurationen och inget VPN-arbete kommer att hjälpa.

Checklista före commit

Bekräfta att scopenamnet matchar de paket som faktiskt publiceras, att standardregistret är explicit och att tokenraden anger rätt värd. Ett stavfel i scopet ger det underligaste felet av alla, eftersom paketet löses upp från det publika registret och returnerar någon annans modul med samma namn. Kontrollera namnet innan du felsöker token.

Bekräfta att det privata registret är nåbart från maskinen i det sammanhang som kör installationen, inte bara från din webbläsare. Den skillnaden spelar roll när en proxy eller en container har annan routning än ditt skal.

Bekräfta sedan beteendet på en ren checkout utan cachade paket. En färsk installation är det enda testet som visar vad en ny kollega kommer att uppleva.