Laat npm het register per pakketscope kiezen, niet de VPN

De VPN verbinden zou niet moeten betekenen dat je de registerinstelling van npm twee keer per dag bewerkt. Een scope-item in een configuratiebestand op projectniveau kan bedrijfspakketten naar één register sturen en al het overige naar het openbare, zonder omschakelen en zonder een overschrijving die op vrijdagmiddag blijft liggen. De addertje onder het gras is dat dit alleen de naamgeving oplost; routing, inloggegevens en configuratievoorrang zijn drie afzonderlijke dingen die elk op hun eigen manier mislukken.

Twee namen, twee bestemmingen

Een npm-pakketnaam heeft wel of geen scope. Een naam met scope begint met een apenstaartje en een scope-identificatie, en juist die identificatie kan de configuratie in kaart brengen. Niets anders aan het pakket is belangrijk voor de toewijzing. Het register ziet nooit een verzoek op basis van of het pakket intern of openbaar is; het ziet alleen een naam.

Het onderstaande bestand drukt dus twee bedoelingen uit in drie regels: openbare pakketten gaan naar het openbare register, en pakketten onder de bedrijfsscope gaan met een token voor die host naar het bedrijfsregister.

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

Vervang de scope, de host en de variabelenaam door wat de organisatie werkelijk biedt. De structuur is belangrijk, niet de voorbeeldwaarden. Twee regels configuratie dragen het hele beleid, daarom is het de moeite waard ze te begrijpen in plaats van te kopiëren.

Houd de toewijzing en het netwerk in gescheiden vakken in je hoofd. Een scope-item kan een onbereikbare host niet bereikbaar maken, en een werkende tunnel kan npm niet vertellen bij welk register een pakket hoort.

Schrijf het bestand in de juiste volgorde

Zet het projectbestand voorop in je redenering, ook al leest npm meerdere bestanden. Een .npmrc in de projectmap is degene die je collega's via de repository erven, dus het zou het gedeelde beleid moeten uitdrukken en niet je persoonlijke token. Dat bestand is ook degene die een reviewer leest. Houd het klein genoeg om in één oogopslag te beoordelen.

Laat de standaardregel registry naar het openbare register wijzen, tenzij de organisatie anders heeft besloten. Als je die verwijdert, is de machine afhankelijk van wat het bestand op gebruikersniveau zegt, en dat is precies het soort impliciete afhankelijkheid dat op twee laptops verschillende resultaten geeft.

De scoplijn is geen jokerteken. Een naam buiten de scope blijft de standaard gebruiken, en dat is het gedrag dat je wilt voor elke afhankelijkheid die je niet zelf hebt geschreven.

Controleer waar het bestand naar oplost voordat je het vastlegt, met een wegwerppakketnaam in plaats van een echte installatie, zodat een fout niets kost.

Inloggegevens horen bij een host, niet bij een project

Authenticatie-items zijn gekoppeld aan een registerhost en, waar het register dat nodig heeft, aan een pad. Daarom begint de tokenregel met de dubbele schuine streep en de host in plaats van de scope. Zodra je de host op die plek ziet, ziet de rest van de regel er niet meer uit als willekeurige leestekens. Het is een adres, en het token hangt eraan.

Een omgevingsvariabele gebruiken houdt het letterlijke token buiten het bestand in de repository. Het maakt het token niet overal onzichtbaar; het verschijnt nog steeds in de procesomgeving, en een opdracht die de configuratie afdrukt kan het onthullen.

Zorg voor de variabele via welk lokaal of CI-inloggegevensmechanisme de organisatie ook goedkeurt, en plak nooit een echt token in een voorbeeld dat naar de documentatie kan worden gekopieerd.

Als er twee registers in het spel zijn, krijgt elk zijn eigen item. Een enkele niet-gekwalificeerde tokeninstelling is op zijn best dubbelzinnig en op zijn slechtst naar de verkeerde host gestuurd.

Wanneer het verkeerde register wint

Configuratie is gelaagd, en de geldende waarde is niet noodzakelijk de waarde in het bestand dat je net hebt bewerkt. Projectinstellingen, gebruikersinstellingen, globale instellingen en omgevingsvariabelen doen allemaal mee. Die gelaagdheid is de reden dat een oplossing op jouw machine werkt en niet in de container van een collega. Het is ook de reden dat het de moeite waard is de effectieve waarde af te drukken voordat je erover discussieert.

De omgevingsvariabele is de gebruikelijke schuldige in CI, waar een taak het register één keer instelt en elke volgende stap het erft. De op één na meest voorkomende is een bestand op gebruikersniveau op de machine van een ontwikkelaar dat overschrijft wat de repository zegt.

Druk de effectieve configuratie en het opgeloste register af voor één naam met scope en één zonder scope voordat je iets anders debugt. Als die twee antwoorden zijn wat je verwacht, is het probleem het netwerk; zo niet, dan is het probleem de configuratie en geen enkele VPN-werkzaamheid zal helpen.

Checklist voordat je vastlegt

Bevestig dat de scopennaam overeenkomt met de pakketten die daadwerkelijk zijn gepubliceerd, dat het standaardregister expliciet is en dat de tokenregel de juiste host noemt. Een typefout in de scope levert de vreemdste storing van allemaal op, omdat het pakket uit het openbare register wordt opgelost en de module van iemand anders met dezelfde naam teruggeeft. Controleer de naam voordat je het token debugt.

Bevestig dat het privéregister bereikbaar is vanaf de machine in de context die de installatie uitvoert, niet alleen vanaf je browser. Dat onderscheid is belangrijk wanneer een proxy of een container een andere routing heeft dan je shell.

Bevestig daarna het gedrag op een schone checkout zonder gecachte pakketten. Een verse installatie is de enige test die laat zien wat een nieuwe collega zal ervaren.