VPN:n yhdistämisen ei pitäisi tarkoittaa npmin rekisteriasetuksen muokkaamista kahdesti päivässä. Projektitason asetustiedostossa oleva laajuusmerkintä voi lähettää yrityksen paketit yhteen rekisteriin ja kaiken muun julkiseen, ilman vaihtamista ja ilman perjantai-iltapäivänä jäljelle jäävää ohitusta. Hankaluus on, että tämä ratkaisee vain nimeämisen; reititys, tunnistetiedot ja asetusten ensisijaisuus ovat kolme erillistä asiaa, jotka kukin epäonnistuvat omalla tavallaan.

Kaksi nimeä, kaksi kohdetta

npm-paketin nimellä on joko laajuus tai ei ole. Laajuudellinen nimi alkaa @-merkistä ja laajuustunnisteesta, ja juuri sen tunnisteen asetukset voivat kuvata. Mikään muu paketissa ei ole kuvauksen kannalta olennaista. Rekisteri ei koskaan näe pyyntöä sen perusteella, onko paketti sisäinen vai julkinen; se näkee vain nimen.

Niinpä alla oleva tiedosto ilmaisee kaksi aikomusta kolmella rivillä: julkiset paketit menevät julkiseen rekisteriin ja yrityksen laajuuden alla olevat paketit menevät yrityksen rekisteriin kyseisen isännän tunnisteella.

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

Korvaa laajuus, isäntä ja muuttujan nimi sillä, mitä organisaatio todella tarjoaa. Rakenne on tärkeä, eivät esimerkkiarvot. Kaksi asetusriviä kantaa koko käytännön, siksi ne kannattaa ymmärtää eikä kopioida.

Pidä kuvaus ja verkko erillisissä lokeroissa päässäsi. Laajuusmerkintä ei voi tehdä saavuttamatonta isäntää saavutettavaksi, eikä toimiva tunneli voi kertoa npm:lle, mihin rekisteriin paketti kuuluu.

Kirjoita tiedosto oikeassa järjestyksessä

Laita projektitiedosto ensimmäiseksi päättelyssäsi, vaikka npm lukee useita tiedostoja. Projektihakemiston .npmrc on se, jonka kollegasi perivät versionhallinnan kautta, joten sen pitäisi ilmaista yhteinen käytäntö eikä henkilökohtaista tunnistettasi. Se tiedosto on myös se, jonka katselmoija lukee. Pidä se riittävän pienenä yhdellä silmäyksellä tarkistettavaksi.

Jätä oletusarvoinen registry-rivi osoittamaan julkiseen rekisteriin, ellei organisaatio ole päättänyt toisin. Sen poistaminen tekee koneesta riippuvaisen siitä, mitä käyttäjätason tiedosto sanoo, ja juuri sellainen implisiittinen riippuvuus tuottaa erilaisia tuloksia kahdella kannettavalla.

Laajuusrivi ei ole jokerimerkki. Laajuuden ulkopuolinen nimi käyttää edelleen oletusta, ja se on käyttäytyminen, jonka haluat jokaiselle riippuvuudelle, jota et kirjoittanut itse.

Tarkista, mihin tiedosto ratkeaa ennen sen committaamista, käyttäen kertakäyttöistä paketin nimeä todellisen asennuksen sijaan, jotta virhe ei maksa mitään.

Tunnistetiedot kuuluvat isännälle, eivät projektille

Todennusmerkinnät on sidottu rekisteri-isäntään ja, missä rekisteri sitä tarvitsee, polkuun. Siksi tunnisterivi alkaa kaksoisvinoviivalla ja isännällä eikä laajuudella. Kun näet isännän siinä kohdassa, rivin loppuosa lakkaa näyttämästä satunnaiselta välimerkiltä. Se on osoite, ja tunniste on kiinnitetty siihen.

Ympäristömuuttujan käyttäminen pitää kirjaimellisen tunnisteen poissa versionhallinnan tiedostosta. Se ei tee tunnisteesta näkymätöntä kaikkialla; se näkyy edelleen prosessin ympäristössä, ja asetukset tulostava komento voi paljastaa sen.

Hanki muuttuja millä tahansa paikallisella tai CI-tunnistetietomekanismilla, jonka organisaatio hyväksyy, äläkä koskaan liitä oikeaa tunnistetta esimerkkiin, joka saatetaan kopioida dokumentaatioon.

Jos kaksi rekisteriä on pelissä, kumpikin saa oman merkintänsä. Yksi yksittäinen kvalifioimaton tunnisteasetus on parhaimmillaan monitulkintainen ja pahimmillaan lähetetty väärälle isännälle.

Kun väärä rekisteri voittaa

Asetukset ovat kerroksellisia, eikä voimassa oleva arvo ole välttämättä arvo tiedostossa, jota juuri muokkasit. Projektiasetukset, käyttäjäasetukset, globaalit asetukset ja ympäristömuuttujat osallistuvat kaikki. Tämä kerroksellisuus on syy siihen, miksi korjaus toimii koneellasi mutta ei kollegan kontissa. Se on myös syy siihen, miksi voimassa oleva arvo kannattaa tulostaa ennen kuin siitä väittelee.

Ympäristömuuttuja on tavallinen syyllinen CI:ssä, jossa työ asettaa rekisterin kerran ja jokainen myöhempi vaihe perii sen. Toiseksi yleisin on kehittäjän koneella oleva käyttäjätason tiedosto, joka ohittaa sen, mitä versionhallinta sanoo.

Tulosta voimassa oleva asetustieto ja ratkaistu rekisteri yhdelle laajuudelliselle ja yhdelle laajuudettomalle nimelle ennen kuin korjaat mitään muuta. Jos nämä kaksi vastausta ovat odottamasi, ongelma on verkossa; jos eivät, ongelma on asetuksissa eikä mikään VPN-työ auta.

Tarkistuslista ennen committaamista

Varmista, että laajuusnimi vastaa todella julkaistuja paketteja, että oletusrekisteri on selkeä ja että tunnisterivi nimeää oikean isännän. Kirjoitusvirhe laajuudessa aiheuttaa kaikkein omituisimman vian, koska paketti ratkeaa julkisesta rekisteristä ja palauttaa jonkun toisen samannimisen moduulin. Tarkista nimi ennen kuin korjaat tunnistetta.

Varmista, että yksityinen rekisteri on saavutettavissa koneesta siinä kontekstissa, joka suorittaa asennuksen, ei vain selaimestasi. Tämä ero on merkityksellinen, kun välityspalvelimella tai kontilla on eri reititys kuin komentotulkillasi.

Varmista sitten käyttäytyminen puhtaassa ulosotossa ilman välimuistiin tallennettuja paketteja. Tuore asennus on ainoa testi, joka näyttää, mitä uusi kollega kokee.

Aiheeseen liittyvät artikkelit