Ať npm vybírá registr podle rozsahu balíčku, ne podle VPN

Připojení k VPN by nemělo znamenat dvakrát denně upravovat nastavení registru v npm. Záznam rozsahu v konfiguračním souboru na úrovni projektu může posílat firemní balíčky do jednoho registru a vše ostatní do veřejného, bez přepínání a bez přepsání, které zůstane zapomenuté v pátek odpoledne. Háček je v tom, že to řeší jen pojmenování; směrování, přihlašovací údaje a priorita konfigurace jsou tři oddělené věci, z nichž každá selhává po svém.

Dvě jména, dvě cíle

Jméno balíčku npm buď rozsah má, nebo nemá. Jméno s rozsahem začíná znakem @ a identifikátorem rozsahu a právě tento identifikátor může konfigurace namapovat. Nic jiného na balíčku pro mapování nezáleží. Registr nikdy nevidí požadavek na základě toho, zda je balíček interní nebo veřejný; vidí jen jméno.

Soubor níže tedy vyjadřuje dva záměry ve třech řádcích: veřejné balíčky jdou do veřejného registru a balíčky pod firemním rozsahem jdou do firemního registru s tokenem pro tento hostitel.

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

Nahraďte rozsah, hostitele a název proměnné tím, co organizace skutečně poskytuje. Důležitá je struktura, ne ukázkové hodnoty. Dva řádky konfigurace nesou celou politiku, a proto stojí za to jim rozumět, místo aby se kopírovaly.

Držte mapování a síť v oddělených přihrádkách v hlavě. Záznam rozsahu nemůže udělat nedostupného hostitele dostupným a fungující tunel nemůže npm říct, ke kterému registru balíček patří.

Napište soubor ve správném pořadí

Postavte projektový soubor ve svém uvažování na první místo, i když npm čte několik souborů. .npmrc v adresáři projektu je ten, který vaši kolegové dědí přes repozitář, takže by měl vyjadřovat sdílenou politiku, ne váš osobní token. Tento soubor je také ten, který bude číst recenzent. Udržte ho dost malý, aby se dal přehlédnout jedním pohledem.

Nechte výchozí řádek registry ukazovat na veřejný registr, pokud se organizace nerozhodla jinak. Jeho odstranění učiní stroj závislým na tom, co říká soubor na úrovni uživatele, a to je právě ten druh implicitní závislosti, která dává různé výsledky na dvou noteboocích.

Řádek rozsahu není zástupný znak. Jméno mimo rozsah dál používá výchozí hodnotu, a to je chování, které chcete pro každou závislost, kterou jste sami nenapsali.

Než soubor potvrdíte, ověřte, na co se překládá, a to pomocí jednorázového názvu balíčku místo skutečné instalace, aby chyba nic nestála.

Přihlašovací údaje patří hostiteli, ne projektu

Záznamy ověřování jsou vázány na hostitele registru a tam, kde to registr potřebuje, na cestu. Proto řádek s tokenem začíná dvojitým lomítkem a hostitelem, ne rozsahem. Jakmile hostitele na té pozici uvidíte, zbytek řádku přestane vypadat jako náhodná interpunkce. Je to adresa a token je k ní připojen.

Použití proměnné prostředí drží doslovný token mimo soubor v repozitáři. Nečiní token neviditelným všude; stále se objevuje v prostředí procesu a příkaz, který vypisuje konfiguraci, ho může odhalit.

Zajistěte proměnnou přes jakýkoli místní nebo CI mechanismus přihlašovacích údajů, který organizace schválí, a nikdy nevkládejte skutečný token do příkladu, který by mohl být zkopírován do dokumentace.

Pokud jsou ve hře dva registry, každý dostane vlastní záznam. Jediné nekvalifikované nastavení tokenu je v nejlepším případě nejednoznačné a v nejhorším odeslané špatnému hostiteli.

Když vyhraje špatný registr

Konfigurace je vrstvená a platná hodnota nemusí být hodnotou v souboru, který jste právě upravili. Nastavení projektu, nastavení uživatele, globální nastavení a proměnné prostředí se všechny účastní. Toto vrstvení je důvod, proč oprava funguje na vašem stroji a ne v kolegově kontejneru. Je to také důvod, proč se vyplatí platnou hodnotu vypsat, než o ní začnete diskutovat.

Proměnná prostředí je obvyklý viník v CI, kde úloha nastaví registr jednou a každý další krok ho zdědí. Druhým nejčastějším je soubor na úrovni uživatele na vývojářově stroji, který přepisuje to, co říká repozitář.

Vypište platnou konfiguraci a přeložený registr pro jedno jméno s rozsahem a jedno bez rozsahu, než začnete ladit cokoli jiného. Pokud jsou tyto dvě odpovědi tím, co očekáváte, je problém v síti; pokud ne, je problém v konfiguraci a žádná práce s VPN nepomůže.

Kontrolní seznam před potvrzením

Ověřte, že název rozsahu odpovídá skutečně publikovaným balíčkům, že výchozí registr je výslovný a že řádek s tokenem uvádí správného hostitele. Překlep v rozsahu způsobí tu nejpodivnější poruchu ze všech, protože balíček se přeloží z veřejného registru a vrátí cizí modul se stejným názvem. Ověřte název, než začnete ladit token.

Ověřte, že soukromý registr je dostupný ze stroje v kontextu, který spouští instalaci, ne jen z vašeho prohlížeče. Tento rozdíl je důležitý, když proxy nebo kontejner má jiné směrování než váš shell.

Poté ověřte chování na čistém checkoutu bez balíčků v mezipaměti. Čerstvá instalace je jediný test, který ukáže, co zažije nový kolega.