Lëreni npm të zgjedhë regjistrin sipas scope-it të paketës, jo sipas VPN-së

Lidhja e VPN-së nuk duhet të nënkuptojë ndryshimin e cilësimit të regjistrit të npm dy herë në ditë. Një zë scope në një skedar konfigurimi në nivel projekti mund t’i dërgojë paketat e kompanisë në një regjistër dhe gjithçka tjetër në atë publik, pa ndërrim dhe pa një override të mbetur pas një pasdite të premte. Kapja është se kjo zgjidh vetëm emërtimin; rrugëtimi, kredencialet dhe përparësia e konfigurimit janë tre gjëra të ndara që dështojnë secila në mënyrën e vet.

Dy emra, dy destinacione

Emri i një pakete npm ose ka scope ose nuk ka. Një emër me scope fillon me një shenjë at dhe një identifikues scope, dhe pikërisht ai identifikues mund të mapohet nga konfigurimi. Asgjë tjetër rreth paketës nuk ka rëndësi për mapimin. Regjistri nuk sheh kurrë një kërkesë të bazuar në faktin nëse paketa është e brendshme apo publike; ai sheh vetëm një emër.

Pra skedari më poshtë shpreh dy qëllime në tre rreshta: paketat publike shkojnë në regjistrin publik, dhe paketat nën scope-in e kompanisë shkojnë në regjistrin e kompanisë me një token për atë host.

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

Zëvendësoni scope-in, hostin dhe emrin e variablit me atë që ofron në të vërtetë organizata. Ajo që ka rëndësi është struktura, jo vlerat e shembullit. Dy rreshta konfigurimi mbajnë të gjithë politikën, prandaj ia vlen t’i kuptoni në vend që t’i kopjoni.

Mbajeni mapimin dhe rrjetin në ndarje të veçanta në mendjen tuaj. Një zë scope nuk mund ta bëjë të arritshëm një host të paarritshëm, dhe një tunel që funksionon nuk mund t’i thotë npm-it se cilit regjistër i përket një paketë.

Shkruajeni skedarin në rendin e duhur

Vendoseni skedarin e projektit të parin në arsyetimin tuaj edhe pse npm lexon disa skedarë. Një .npmrc në drejtorinë e projektit është ai që kolegët tuaj trashëgojnë përmes repository-t, prandaj duhet të shprehë politikën e përbashkët dhe jo token-in tuaj personal. Po ai skedar është edhe ai që do të lexojë një recensues. Mbajeni aq të vogël sa të rishikohet me një shikim.

Lëreni rreshtin e parazgjedhur registry të tregojë regjistrin publik, përveç nëse organizata ka vendosur ndryshe. Heqja e tij e bën makinën të varur nga ajo që thotë skedari i nivelit të përdoruesit, që është pikërisht lloji i varësisë implicite që prodhon rezultate të ndryshme në dy laptopë.

Rreshti i scope-it nuk është një karakter zëvendësues. Një emër jashtë scope-it vazhdon të përdorë parazgjedhjen, që është sjellja që dëshironi për çdo varësi që nuk e keni shkruar vetë.

Kontrolloni se çfarë rezulton skedari përpara se ta bëni commit, duke përdorur një emër pakete të përkohshme në vend të një instalimi të vërtetë, kështu që një gabim nuk kushton asgjë.

Kredencialet i përkasin një hosti, jo një projekti

Zërat e vërtetimit janë të lidhur me një host regjistri dhe, aty ku regjistri e kërkon, me një shteg. Kjo është arsyeja pse rreshti i token-it fillon me slash-in e dyfishtë dhe hostin në vend të scope-it. Pasi ta shihni hostin në atë pozicion, pjesa tjetër e rreshtit nuk duket më si pikësim arbitrar. Është një adresë, dhe token-i është i bashkangjitur asaj.

Përdorimi i një variabli mjedisi e mban token-in literal jashtë skedarit në repository. Nuk e bën token-in të padukshëm kudo; ai shfaqet ende në mjedisin e procesit, dhe një komandë që shtyp konfigurimin mund ta zbulojë atë.

Prokuroni variablin përmes çdo mekanizmi kredencialesh lokal ose CI që organizata miraton, dhe mos ngjitni kurrë një token të vërtetë në një shembull që mund të kopjohet në dokumentacion.

Nëse janë në lojë dy regjistra, secili merr zërin e vet. Një cilësim i vetëm token-i i pakualifikuar është në rastin më të mirë i paqartë dhe në rastin më të keq i dërguar hostit të gabuar.

Kur fiton regjistri i gabuar

Konfigurimi është i shtresuar, dhe vlera në fuqi nuk është domosdoshmërisht vlera në skedarin që sapo redaktuam. Cilësimet e projektit, cilësimet e përdoruesit, cilësimet globale dhe variablat e mjedisit marrin të gjitha pjesë. Ky shtresim është arsyeja pse një rregullim funksionon në makinën tuaj dhe jo në kontejnerin e një kolegu. Është gjithashtu arsyeja pse ia vlen të shtypet vlera efektive përpara se të debatoni rreth saj.

Një variabël mjedisi është fajtori i zakonshëm në CI, ku një punë vendos një regjistër një herë dhe çdo hap i mëvonshëm e trashëgon atë. I dyti më i zakonshmi është një skedar në nivel përdoruesi në makinën e një zhvilluesi që anulon atë që thotë repository.

Shtypni konfigurimin efektiv dhe regjistrin e zgjidhur për një emër me scope dhe një pa të, përpara se të korrigjoni ndonjë gjë tjetër. Nëse ato dy përgjigje janë ato që prisni, problemi është rrjeti; nëse nuk janë, problemi është konfigurimi dhe asnjë sasi pune me VPN nuk do të ndihmojë.

Lista e kontrollit përpara commit-it

Konfirmoni që emri i scope-it përputhet me paketat e publikuara në të vërtetë, që regjistri i parazgjedhur është i shprehur dhe që rreshti i token-it emërton hostin e saktë. Një gabim shtypi në scope prodhon dështimin më të çuditshëm nga të gjithë, sepse paketa zgjidhet nga regjistri publik dhe kthen modulin e dikujt tjetër me të njëjtin emër. Kontrolloni emrin përpara se të korrigjoni token-in.

Konfirmoni që regjistri privat është i arritshëm nga makina në kontekstin që ekzekuton instalimin, jo vetëm nga shfletuesi juaj. Ky dallim ka rëndësi kur një proxy ose një kontejner ka rrugëtim të ndryshëm nga shell-i juaj.

Pastaj konfirmoni sjelljen në një checkout të pastër pa paketa të ruajtura në cache. Një instalim i freskët është i vetmi test që tregon se çfarë do të përjetojë një koleg i ri.