Az npm válassza ki a regisztert a csomag hatóköre szerint, ne a VPN

A VPN-hez csatlakozás nem jelentheti azt, hogy naponta kétszer szerkesztjük az npm regiszterbeállítását. Egy hatókör-bejegyzés a projekt szintű konfigurációs fájlban elküldheti a cég csomagjait az egyik regiszterbe, minden mást pedig a nyilvánosba, kapcsolgatás nélkül és péntek délután hátrahagyott felülírás nélkül. A bökkenő az, hogy ez csak az elnevezést oldja meg; az útválasztás, a hitelesítő adatok és a konfiguráció elsőbbsége három külön dolog, amelyek mindegyike a maga módján hibázik.

Két név, két cél

Az npm csomagnévnek vagy van hatóköre, vagy nincs. A hatókörrel rendelkező név @ jellel és hatókör-azonosítóval kezdődik, és pontosan ezt az azonosítót tudja leképezni a konfiguráció. Semmi más nem számít a csomagon a leképezéshez. A regiszter soha nem lát kérést aszerint, hogy a csomag belső vagy nyilvános; csak egy nevet lát.

Az alábbi fájl tehát két szándékot fejez ki három sorban: a nyilvános csomagok a nyilvános regiszterbe mennek, a cég hatóköre alatti csomagok pedig a cég regiszterébe, az adott hoszthoz tartozó tokennel.

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

Cserélje ki a hatókört, a hostot és a változó nevét arra, amit a szervezet valóban biztosít. A szerkezet számít, nem a példaértékek. Két konfigurációs sor hordozza a teljes szabályzatot, ezért érdemes megérteni őket a másolás helyett.

Tartsa a leképezést és a hálózatot külön rekeszekben a fejében. A hatókör-bejegyzés nem tehet elérhetővé egy elérhetetlen hostot, és egy működő alagút nem mondhatja meg az npm-nek, melyik regiszterhez tartozik egy csomag.

Írja a fájlt a megfelelő sorrendben

Tegye a projektfájlt első helyre a gondolkodásában, pedig az npm több fájlt olvas. A projektkönyvtárban lévő .npmrc az, amelyet a kollégái a tárolón keresztül örökölnek, ezért a közös szabályzatot kell kifejeznie, nem a személyes tokenjét. Ez a fájl az is, amelyet egy bíráló olvasni fog. Tartsa elég kicsinek ahhoz, hogy egy pillantással át lehessen nézni.

Hagyja az alapértelmezett registry sort a nyilvános regiszterre mutatni, kivéve ha a szervezet másképp döntött. Az eltávolítása a felhasználói szintű fájltól teszi függővé a gépet, és pontosan ez az a fajta implicit függőség, amely két laptopon eltérő eredményt ad.

A hatókörsor nem helyettesítő karakter. A hatókörön kívüli név továbbra is az alapértelmezést használja, és ez az a viselkedés, amelyet minden olyan függőségnél szeretne, amelyet nem Ön írt.

Ellenőrizze, mire oldódik fel a fájl, mielőtt véglegesíti, eldobható csomagnévvel a valódi telepítés helyett, hogy egy hiba ne kerüljön semmibe.

A hitelesítő adatok a hosthoz tartoznak, nem a projekthez

A hitelesítési bejegyzések egy regiszter-hosthoz és, ahol a regiszter igényli, egy útvonalhoz vannak kötve. Ezért kezdődik a token sor a kettős perjellel és a hosttal, nem a hatókörrel. Amint meglátja a hostot ebben a helyzetben, a sor többi része megszűnik önkényes írásjelnek tűnni. Ez egy cím, és a token hozzá van csatolva.

A környezeti változó használata a szó szerinti tokent a tárolóban lévő fájlon kívül tartja. Ez nem teszi a tokent mindenhol láthatatlanná; továbbra is megjelenik a folyamat környezetében, és a konfigurációt kiíró parancs felfedheti.

Biztosítsa a változót a szervezet által jóváhagyott helyi vagy CI hitelesítő mechanizmuson keresztül, és soha ne illesszen valódi tokent olyan példába, amely a dokumentációba másolható.

Ha két regiszter van játékban, mindegyik saját bejegyzést kap. Egyetlen minősítés nélküli tokenbeállítás a legjobb esetben kétértelmű, a legrosszabb esetben pedig a rossz hostnak küldik.

Amikor a rossz regiszter nyer

A konfiguráció rétegezett, és az érvényes érték nem feltétlenül az imént szerkesztett fájlban lévő érték. A projektbeállítások, a felhasználói beállítások, a globális beállítások és a környezeti változók mind részt vesznek. Ez a rétegződés az oka annak, hogy egy javítás az Ön gépén működik, egy kolléga konténerében pedig nem. Ez az oka annak is, hogy érdemes kiírni az effektív értéket, mielőtt vitatkozni kezd róla.

A környezeti változó a szokásos bűnös a CI-ben, ahol egy feladat egyszer beállítja a regisztert, és minden későbbi lépés örökli. A második leggyakoribb a fejlesztő gépén lévő felhasználói szintű fájl, amely felülírja azt, amit a tároló mond.

Írja ki az effektív konfigurációt és a feloldott regisztert egy hatókörrel rendelkező és egy hatókör nélküli névre, mielőtt bármi mást hibakeresne. Ha ez a két válasz az, amit vár, a probléma a hálózat; ha nem, a probléma a konfiguráció, és semmilyen VPN-munka nem segít.

Ellenőrzőlista a véglegesítés előtt

Erősítse meg, hogy a hatókör neve megfelel a ténylegesen közzétett csomagoknak, hogy az alapértelmezett regiszter explicit, és hogy a token sor a helyes hostot nevezi meg. Egy elírás a hatókörben a legfurcsább hibát okozza, mert a csomag a nyilvános regiszterből oldódik fel, és valaki más azonos nevű modulját adja vissza. Ellenőrizze a nevet, mielőtt a tokent hibakeresi.

Erősítse meg, hogy a privát regiszter elérhető arról a gépről abban a környezetben, amely a telepítést futtatja, nem csak a böngészőjéből. Ez a különbség számít, amikor egy proxy vagy konténer útválasztása eltér a héjétól.

Ezután erősítse meg a viselkedést egy tiszta kivételen gyorsítótárazott csomagok nélkül. A friss telepítés az egyetlen teszt, amely megmutatja, mit fog tapasztalni egy új kolléga.