Pozwól npm wybierać rejestr według zakresu pakietu, a nie VPN

Połączenie z VPN nie powinno oznaczać edytowania ustawienia rejestru npm dwa razy dziennie. Wpis zakresu w pliku konfiguracyjnym na poziomie projektu może wysyłać pakiety firmy do jednego rejestru, a wszystko inne do publicznego, bez przełączania i bez nadpisania zostawionego w piątkowe popołudnie. Haczyk polega na tym, że rozwiązuje to tylko nazewnictwo; routing, poświadczenia i pierwszeństwo konfiguracji to trzy osobne rzeczy, z których każda zawodzi na swój sposób.

Dwie nazwy, dwa cele

Nazwa pakietu npm albo ma zakres, albo go nie ma. Nazwa z zakresem zaczyna się od znaku @ i identyfikatora zakresu, i właśnie ten identyfikator konfiguracja może zmapować. Nic innego w pakiecie nie ma znaczenia dla mapowania. Rejestr nigdy nie widzi żądania na podstawie tego, czy pakiet jest wewnętrzny czy publiczny; widzi tylko nazwę.

Dlatego plik poniżej wyraża dwa zamiary w trzech liniach: pakiety publiczne trafiają do rejestru publicznego, a pakiety w ramach zakresu firmy trafiają do rejestru firmy z tokenem dla tego hosta.

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

Zastąp zakres, hosta i nazwę zmiennej tym, co organizacja rzeczywiście zapewnia. Ważna jest struktura, a nie przykładowe wartości. Dwie linie konfiguracji niosą całą politykę, dlatego warto je zrozumieć, a nie kopiować.

Trzymaj mapowanie i sieć w oddzielnych przegródkach w głowie. Wpis zakresu nie może uczynić nieosiągalnego hosta osiągalnym, a działający tunel nie może powiedzieć npm, do którego rejestru należy pakiet.

Napisz plik we właściwej kolejności

Postaw plik projektu na pierwszym miejscu w swoim rozumowaniu, choć npm czyta kilka plików. .npmrc w katalogu projektu jest tym, który twoi współpracownicy dziedziczą przez repozytorium, więc powinien wyrażać wspólną politykę, a nie twój osobisty token. Ten plik to także ten, który przeczyta recenzent. Trzymaj go na tyle małym, by dało się go przejrzeć jednym spojrzeniem.

Zostaw domyślną linię registry wskazującą na rejestr publiczny, chyba że organizacja zdecydowała inaczej. Usunięcie jej sprawia, że maszyna zależy od tego, co mówi plik na poziomie użytkownika, a to dokładnie ten rodzaj ukrytej zależności, który daje różne wyniki na dwóch laptopach.

Linia zakresu nie jest znakiem wieloznacznym. Nazwa spoza zakresu nadal używa wartości domyślnej, i to jest zachowanie, którego chcesz dla każdej zależności, której nie napisałeś sam.

Sprawdź, na co plik się rozwiązuje, zanim go zatwierdzisz, używając jednorazowej nazwy pakietu zamiast prawdziwej instalacji, żeby błąd nic nie kosztował.

Poświadczenia należą do hosta, nie do projektu

Wpisy uwierzytelniania są powiązane z hostem rejestru i, gdy rejestr tego wymaga, ze ścieżką. Dlatego linia tokenu zaczyna się od podwójnego ukośnika i hosta, a nie od zakresu. Gdy zobaczysz hosta w tej pozycji, reszta linii przestaje wyglądać jak przypadkowa interpunkcja. To adres, a token jest do niego przypięty.

Użycie zmiennej środowiskowej trzyma dosłowny token poza plikiem w repozytorium. Nie czyni to tokenu niewidocznym wszędzie; nadal pojawia się w środowisku procesu, a polecenie drukujące konfigurację może go ujawnić.

Zapewnij zmienną przez dowolny lokalny lub CI-owy mechanizm poświadczeń, który zatwierdza organizacja, i nigdy nie wklejaj prawdziwego tokenu do przykładu, który może zostać skopiowany do dokumentacji.

Jeśli w grze są dwa rejestry, każdy dostaje własny wpis. Jedno niekwalifikowane ustawienie tokenu jest w najlepszym razie niejednoznaczne, a w najgorszym wysłane do niewłaściwego hosta.

Kiedy wygrywa niewłaściwy rejestr

Konfiguracja jest warstwowa, a obowiązująca wartość nie musi być wartością w pliku, który właśnie edytowałeś. Ustawienia projektu, ustawienia użytkownika, ustawienia globalne i zmienne środowiskowe wszystkie uczestniczą. To warstwowanie jest powodem, dla którego poprawka działa na twojej maszynie, a nie w kontenerze współpracownika. To także powód, dla którego warto wydrukować efektywną wartość, zanim zaczniesz o niej dyskutować.

Zmienna środowiskowa to zwykły winowajca w CI, gdzie zadanie ustawia rejestr raz, a każdy późniejszy krok go dziedziczy. Drugi najczęstszy to plik na poziomie użytkownika na maszynie dewelopera, który nadpisuje to, co mówi repozytorium.

Wydrukuj efektywną konfigurację i rozwiązany rejestr dla jednej nazwy z zakresem i jednej bez zakresu, zanim zaczniesz debugować cokolwiek innego. Jeśli te dwie odpowiedzi są tym, czego oczekujesz, problemem jest sieć; jeśli nie, problemem jest konfiguracja i żadna praca z VPN nie pomoże.

Lista kontrolna przed zatwierdzeniem

Potwierdź, że nazwa zakresu odpowiada faktycznie opublikowanym pakietom, że domyślny rejestr jest wyraźny i że linia tokenu wskazuje właściwego hosta. Literówka w zakresie daje najdziwniejszą awarię ze wszystkich, ponieważ pakiet rozwiązuje się z rejestru publicznego i zwraca cudzy moduł o tej samej nazwie. Sprawdź nazwę, zanim zaczniesz debugować token.

Potwierdź, że prywatny rejestr jest osiągalny z maszyny w kontekście, który uruchamia instalację, a nie tylko z twojej przeglądarki. Ta różnica ma znaczenie, gdy proxy lub kontener ma inny routing niż twoja powłoka.

Następnie potwierdź zachowanie na czystym checkoucie bez pakietów w pamięci podręcznej. Świeża instalacja to jedyny test, który pokazuje, czego doświadczy nowy współpracownik.