VPN değil, paket scope'una göre npm registry seçsin

VPN'e bağlanmak, npm'in registry ayarını günde iki kez düzenlemek anlamına gelmemeli. Proje düzeyindeki bir yapılandırma dosyasındaki scope girdisi, şirket paketlerini bir registry'ye, geri kalan her şeyi genel olana gönderebilir; geçiş yapmadan ve cuma öğleden sonrasına kalan bir override bırakmadan. İşin püf noktası şu: bu yalnızca adlandırmayı çözer; yönlendirme, kimlik bilgileri ve yapılandırma önceliği, her biri kendi biçiminde başarısız olan üç ayrı şeydir.

İki ad, iki hedef

Bir npm paket adının scope'u ya vardır ya yoktur. Scope'lu bir ad, at işareti ve bir scope tanımlayıcısıyla başlar ve yapılandırmanın eşleyebildiği şey o tanımlayıcıdır. Eşleme için paketle ilgili başka hiçbir şey önemli değildir. Registry, paketin dahili mi genel mi olduğuna dayanan bir isteği asla görmez; yalnızca bir ad görür.

Yani aşağıdaki dosya iki niyeti üç satırda ifade eder: genel paketler genel registry'ye gider, şirket scope'u altındaki paketler ise o host için bir token ile şirket registry'sine gider.

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

Scope'u, host'u ve değişken adını kuruluşun gerçekte sağladığı şeylerle değiştirin. Önemli olan yapıdır, örnek değerler değil. İki satır yapılandırma tüm politikayı taşır, bu yüzden onları kopyalamak yerine anlamak değerlidir.

Eşlemeyi ve ağı kafanızda ayrı bölmelerde tutun. Bir scope girdisi ulaşılamayan bir host'u ulaşılabilir yapamaz ve çalışan bir tünel npm'e bir paketin hangi registry'ye ait olduğunu söyleyemez.

Dosyayı doğru sırayla yazın

npm birkaç dosya okusa da proje dosyasını akıl yürütmenizde ilk sıraya koyun. Proje dizinindeki .npmrc, iş arkadaşlarınızın repository üzerinden devraldığı dosyadır, bu yüzden kişisel token'ınızı değil ortak politikayı ifade etmelidir. Bir gözden geçirenin okuyacağı dosya da odur. Tek bakışta incelenebilecek kadar küçük tutun.

Kuruluş aksini kararlaştırmadıkça varsayılan registry satırını genel registry'yi gösterecek şekilde bırakın. Onu kaldırmak, makineyi kullanıcı düzeyindeki dosyanın söylediğine bağımlı hale getirir; bu da iki dizüstü bilgisayarda farklı sonuçlar üreten tam o tür örtük bağımlılıktır.

Scope satırı bir joker karakter değildir. Scope dışındaki bir ad varsayılanı kullanmaya devam eder; kendiniz yazmadığınız her bağımlılık için istediğiniz davranış budur.

Commit etmeden önce dosyanın neye çözüldüğünü kontrol edin; gerçek bir kurulum yerine geçici bir paket adı kullanın, böylece bir hata hiçbir şeye mal olmaz.

Kimlik bilgileri bir projeye değil, bir host'a aittir

Kimlik doğrulama girdileri bir registry host'una ve registry'nin gerektirdiği yerde bir yola bağlanır. Bu yüzden token satırı scope yerine çift slash ve host ile başlar. Host'u o konumda bir kez gördüğünüzde, satırın geri kalanı rastgele noktalama gibi görünmeyi bırakır. O bir adrestir ve token ona bağlıdır.

Bir ortam değişkeni kullanmak, gerçek token'ı repository'deki dosyanın dışında tutar. Bu token'ı her yerde görünmez yapmaz; hâlâ süreç ortamında görünür ve yapılandırmayı yazdıran bir komut onu açığa çıkarabilir.

Değişkeni kuruluşun onayladığı herhangi bir yerel veya CI kimlik bilgisi mekanizması aracılığıyla sağlayın ve gerçek bir token'ı belgelere kopyalanabilecek bir örneğe asla yapıştırmayın.

İki registry devredeyse her biri kendi girdisini alır. Tek bir niteliksiz token ayarı en iyi ihtimalle belirsizdir, en kötü ihtimalle yanlış host'a gönderilir.

Yanlış registry kazandığında

Yapılandırma katmanlıdır ve yürürlükteki değer, az önce düzenlediğiniz dosyadaki değer olmak zorunda değildir. Proje ayarları, kullanıcı ayarları, genel ayarlar ve ortam değişkenleri hepsi katılır. Bu katmanlaşma yüzünden bir düzeltme sizin makinenizde çalışır ama iş arkadaşınızın container'ında çalışmaz. Aynı nedenle, tartışmaya başlamadan önce yürürlükteki değeri yazdırmak değerlidir.

CI'da olağan suçlu bir ortam değişkenidir; bir iş registry'yi bir kez ayarlar ve sonraki her adım onu devralır. İkinci en yaygın olan, repository'nin söylediğini geçersiz kılan, geliştiricinin makinesindeki kullanıcı düzeyinde bir dosyadır.

Başka herhangi bir şeyi ayıklamadan önce scope'lu bir ad ve scope'suz bir ad için yürürlükteki yapılandırmayı ve çözümlenen registry'yi yazdırın. Bu iki yanıt beklediğiniz gibiyse sorun ağdadır; değilse sorun yapılandırmadır ve ne kadar VPN çalışması olursa olsun yardımcı olmaz.

Commit öncesi kontrol listesi

Scope adının gerçekten yayımlanan paketlerle eşleştiğini, varsayılan registry'nin açık olduğunu ve token satırının doğru host'u adlandırdığını doğrulayın. Scope'taki bir yazım hatası hepsinin en tuhaf arızasını üretir, çünkü paket genel registry'den çözümlenir ve aynı ada sahip başka birinin modülünü döndürür. Token'ı ayıklamadan önce adı kontrol edin.

Özel registry'ye yalnızca tarayıcınızdan değil, kurulumu çalıştıran bağlamdaki makineden de ulaşılabildiğini doğrulayın. Bir proxy veya container sizin shell'inizden farklı yönlendirmeye sahip olduğunda bu ayrım önemlidir.

Ardından önbelleğe alınmış paket olmayan temiz bir checkout'ta davranışı doğrulayın. Yeni bir iş arkadaşının ne yaşayacağını gösteren tek test taze kurulumdur.