Lascia che npm scelga il registro in base allo scope del pacchetto, non alla VPN

Collegare la VPN non dovrebbe significare modificare due volte al giorno l’impostazione del registro di npm. Una voce di scope in un file di configurazione a livello di progetto può inviare i pacchetti aziendali a un registro e tutto il resto a quello pubblico, senza cambi di impostazione e senza override lasciati dietro un venerdì pomeriggio. Il problema è che questo risolve solo la denominazione; instradamento, credenziali e precedenza della configurazione sono tre cose separate che falliscono ciascuna a modo proprio.

Due nomi, due destinazioni

Il nome di un pacchetto npm ha uno scope oppure no. Un nome con scope inizia con una chiocciola e un identificatore di scope, ed è quell’identificatore che la configurazione può mappare. Nient’altro del pacchetto conta per la mappatura. Il registro non vede mai una richiesta basata sul fatto che il pacchetto sia interno o pubblico; vede solo un nome.

Quindi il file qui sotto esprime due intenzioni in tre righe: i pacchetti pubblici vanno al registro pubblico, e i pacchetti sotto lo scope aziendale vanno al registro aziendale con un token per quell’host.

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

Sostituisci lo scope, l’host e il nome della variabile con ciò che l’organizzazione fornisce davvero. Conta la struttura, non i valori di esempio. Due righe di configurazione contengono l’intera politica, ed è per questo che vale la pena capirle invece di copiarle.

Tieni la mappatura e la rete in compartimenti separati nella tua testa. Una voce di scope non può rendere raggiungibile un host irraggiungibile, e un tunnel funzionante non può dire a npm a quale registro appartiene un pacchetto.

Scrivi il file nell’ordine giusto

Metti il file di progetto al primo posto nel tuo ragionamento, anche se npm legge diversi file. Un .npmrc nella directory del progetto è quello che i tuoi colleghi ereditano attraverso il repository, quindi dovrebbe esprimere la politica condivisa e non il tuo token personale. Quel file è anche quello che leggerà un revisore. Tienilo abbastanza piccolo da poterlo rivedere con un solo sguardo.

Lascia la riga predefinita registry puntata al registro pubblico, a meno che l’organizzazione non abbia deciso diversamente. Rimuoverla rende la macchina dipendente da ciò che dice il file a livello utente, che è esattamente il tipo di dipendenza implicita che produce risultati diversi su due portatili.

La riga dello scope non è un carattere jolly. Un nome fuori dallo scope continua a usare il valore predefinito, che è il comportamento che vuoi per ogni dipendenza che non hai scritto tu.

Controlla a cosa si risolve il file prima di eseguirne il commit, usando un nome di pacchetto usa e getta invece di un’installazione reale, così un errore non costa nulla.

Le credenziali appartengono a un host, non a un progetto

Le voci di autenticazione sono legate a un host del registro e, dove il registro lo richiede, a un percorso. Ecco perché la riga del token inizia con la doppia barra e l’host invece che con lo scope. Una volta che vedi l’host in quella posizione, il resto della riga smette di sembrare punteggiatura arbitraria. È un indirizzo, e il token è allegato ad esso.

Usare una variabile d’ambiente tiene il token letterale fuori dal file nel repository. Non rende il token invisibile ovunque; compare ancora nell’ambiente del processo, e un comando che stampa la configurazione può rivelarlo.

Fornisci la variabile attraverso qualunque meccanismo di credenziali locale o CI l’organizzazione approvi, e non incollare mai un token reale in un esempio che potrebbe essere copiato nella documentazione.

Se sono in gioco due registri, ognuno riceve la propria voce. Un’unica impostazione di token non qualificata è nella migliore delle ipotesi ambigua e nella peggiore inviata all’host sbagliato.

Quando vince il registro sbagliato

La configurazione è a strati, e il valore in vigore non è necessariamente il valore nel file che hai appena modificato. Impostazioni di progetto, impostazioni utente, impostazioni globali e variabili d’ambiente partecipano tutte. È per questo che una correzione funziona sulla tua macchina e non nel container di un collega. È anche per questo che vale la pena stampare il valore effettivo prima di discuterne.

Una variabile d’ambiente è il colpevole abituale in CI, dove un job imposta un registro una volta e ogni passo successivo lo eredita. Il secondo più comune è un file a livello utente sulla macchina di uno sviluppatore che sovrascrive ciò che dice il repository.

Stampa la configurazione effettiva e il registro risolto per un nome con scope e uno senza prima di fare debug di qualsiasi altra cosa. Se quelle due risposte sono quelle che ti aspetti, il problema è la rete; se non lo sono, il problema è la configurazione e nessuna quantità di lavoro sulla VPN aiuterà.

Lista di controllo prima del commit

Verifica che il nome dello scope corrisponda ai pacchetti effettivamente pubblicati, che il registro predefinito sia esplicito e che la riga del token indichi l’host corretto. Un errore di battitura nello scope produce il guasto più strano di tutti, perché il pacchetto viene risolto dal registro pubblico e restituisce il modulo di qualcun altro con lo stesso nome. Controlla il nome prima di fare debug del token.

Verifica che il registro privato sia raggiungibile dalla macchina nel contesto che esegue l’installazione, non solo dal tuo browser. Questa distinzione conta quando un proxy o un container ha un instradamento diverso da quello della tua shell.

Poi verifica il comportamento su un checkout pulito senza pacchetti in cache. Un’installazione fresca è l’unico test che mostra ciò che proverà un nuovo collega.