Lassen Sie npm das Registry nach Paketbereich wählen, nicht das VPN

Das VPN zu verbinden sollte nicht bedeuten, die Registry-Einstellung von npm zweimal am Tag zu bearbeiten. Ein Scope-Eintrag in einer Konfigurationsdatei auf Projektebene kann Firmenpakete an ein Registry und alles andere an das öffentliche schicken, ohne Umschalten und ohne eine Überschreibung, die am Freitagnachmittag zurückbleibt. Der Haken ist, dass dies nur die Benennung löst; Routing, Anmeldedaten und Konfigurationsvorrang sind drei getrennte Dinge, die jeweils auf ihre eigene Weise scheitern.

Zwei Namen, zwei Ziele

Ein npm-Paketname hat entweder einen Bereich oder nicht. Ein Name mit Bereich beginnt mit einem At-Zeichen und einer Bereichskennung, und genau diese Kennung kann die Konfiguration abbilden. Nichts anderes am Paket ist für die Abbildung wichtig. Das Registry sieht nie eine Anfrage danach, ob das Paket intern oder öffentlich ist; es sieht nur einen Namen.

Die folgende Datei drückt also zwei Absichten in drei Zeilen aus: öffentliche Pakete gehen an das öffentliche Registry, und Pakete unter dem Firmenbereich gehen mit einem Token für diesen Host an das Firmen-Registry.

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

Ersetzen Sie den Bereich, den Host und den Variablennamen durch das, was die Organisation tatsächlich bereitstellt. Die Struktur ist wichtig, nicht die Beispielwerte. Zwei Konfigurationszeilen tragen die ganze Richtlinie, weshalb es sich lohnt, sie zu verstehen, statt sie zu kopieren.

Halten Sie die Abbildung und das Netzwerk in getrennten Fächern im Kopf. Ein Scope-Eintrag kann einen unerreichbaren Host nicht erreichbar machen, und ein funktionierender Tunnel kann npm nicht sagen, zu welchem Registry ein Paket gehört.

Schreiben Sie die Datei in der richtigen Reihenfolge

Setzen Sie die Projektdatei in Ihren Überlegungen an die erste Stelle, obwohl npm mehrere Dateien liest. Eine .npmrc im Projektverzeichnis ist die, die Ihre Kollegen über das Repository erben, also sollte sie die gemeinsame Richtlinie ausdrücken und nicht Ihr persönliches Token. Diese Datei ist auch die, die ein Prüfer lesen wird. Halten Sie sie klein genug, um sie mit einem Blick zu prüfen.

Lassen Sie die Standardzeile registry auf das öffentliche Registry zeigen, sofern die Organisation nichts anderes beschlossen hat. Wird sie entfernt, hängt die Maschine davon ab, was die Datei auf Benutzerebene sagt, und genau das ist die Art impliziter Abhängigkeit, die auf zwei Laptops unterschiedliche Ergebnisse erzeugt.

Die Bereichszeile ist kein Platzhalter. Ein Name außerhalb des Bereichs verwendet weiterhin den Standard, und das ist das Verhalten, das Sie für jede Abhängigkeit wollen, die Sie nicht selbst geschrieben haben.

Prüfen Sie, worauf die Datei sich auflöst, bevor Sie sie festschreiben, mit einem Wegwerf-Paketnamen statt einer echten Installation, damit ein Fehler nichts kostet.

Anmeldedaten gehören zu einem Host, nicht zu einem Projekt

Authentifizierungseinträge sind an einen Registry-Host und, wo das Registry es braucht, an einen Pfad gebunden. Deshalb beginnt die Token-Zeile mit dem doppelten Schrägstrich und dem Host statt mit dem Bereich. Sobald Sie den Host an dieser Stelle sehen, hört der Rest der Zeile auf, wie willkürliche Zeichensetzung auszusehen. Es ist eine Adresse, und das Token hängt daran.

Eine Umgebungsvariable zu verwenden hält das wörtliche Token aus der Datei im Repository heraus. Sie macht das Token nicht überall unsichtbar; es erscheint weiterhin in der Prozessumgebung, und ein Befehl, der die Konfiguration ausgibt, kann es offenlegen.

Stellen Sie die Variable über den lokalen oder CI-Anmeldedatenmechanismus bereit, den die Organisation genehmigt, und kleben Sie niemals ein echtes Token in ein Beispiel, das in die Dokumentation kopiert werden könnte.

Wenn zwei Registries im Spiel sind, bekommt jedes seinen eigenen Eintrag. Eine einzelne unqualifizierte Token-Einstellung ist im besten Fall mehrdeutig und im schlimmsten Fall an den falschen Host geschickt.

Wenn das falsche Registry gewinnt

Konfiguration ist geschichtet, und der wirksame Wert ist nicht unbedingt der Wert in der Datei, die Sie gerade bearbeitet haben. Projekt-Einstellungen, Benutzer-Einstellungen, globale Einstellungen und Umgebungsvariablen wirken alle mit. Diese Schichtung ist der Grund, warum eine Korrektur auf Ihrer Maschine funktioniert und im Container eines Kollegen nicht. Sie ist auch der Grund, warum es sich lohnt, den wirksamen Wert auszugeben, bevor Sie darüber streiten.

Die Umgebungsvariable ist der übliche Übeltäter in CI, wo ein Job das Registry einmal setzt und jeder spätere Schritt es erbt. Der zweithäufigste ist eine Datei auf Benutzerebene auf dem Rechner eines Entwicklers, die überschreibt, was das Repository sagt.

Geben Sie die wirksame Konfiguration und das aufgelöste Registry für einen Namen mit Bereich und einen ohne Bereich aus, bevor Sie irgendetwas anderes debuggen. Wenn diese beiden Antworten Ihren Erwartungen entsprechen, liegt das Problem im Netzwerk; wenn nicht, liegt es an der Konfiguration, und keine VPN-Arbeit wird helfen.

Checkliste vor dem Festschreiben

Bestätigen Sie, dass der Bereichsname zu den tatsächlich veröffentlichten Paketen passt, dass das Standard-Registry explizit ist und dass die Token-Zeile den richtigen Host nennt. Ein Tippfehler im Bereich erzeugt den seltsamsten Fehler von allen, weil das Paket aus dem öffentlichen Registry aufgelöst wird und das Modul von jemand anderem mit demselben Namen zurückgibt. Prüfen Sie den Namen, bevor Sie das Token debuggen.

Bestätigen Sie, dass das private Registry von der Maschine in dem Kontext erreichbar ist, der die Installation ausführt, nicht nur von Ihrem Browser. Dieser Unterschied zählt, wenn ein Proxy oder ein Container ein anderes Routing hat als Ihre Shell.

Bestätigen Sie dann das Verhalten auf einem sauberen Checkout ohne zwischengespeicherte Pakete. Eine frische Installation ist der einzige Test, der zeigt, was ein neuer Kollege erleben wird.