Git deposuna “node_modules” klasörü eklenmeli mi?

Repo bizim node_modules izlemek veya kodu kontrol ederken bir npm yükleme yapıyor merak ediyorum?

Cevap Alberto Zaccagni'nin önerdiği kadar kolay değil. Git deponuzda node_modules dahil olmak üzere uygulamalar (özellikle kurumsal uygulamalar) geliştiriyorsanız, uygun bir seçimdir ve seçtiğiniz alternatif projenize bağlıdır.

Düğüm_modüllerine karşı çok iyi tartıştığı için onlar için tartışmalara yoğunlaşacağım.

Kurumsal uygulamayı yeni bitirdiğinizi ve 3-5 yıl boyunca desteklemeniz gerektiğini düşünün. Kesinlikle yarın kaybolabilecek birinin npm modülüne güvenmek istemezsiniz ve uygulamanızı artık güncelleyemezsiniz.

Veya internetten erişilemeyen özel modülleriniz var ve uygulamanızı internette oluşturamazsınız. Ya da belki bazı nedenlerden dolayı npm hizmetindeki son yapınıza bağlı kalmak istemezsiniz.

Bu Addy Osmani makalesinde artıları ve eksileri bulabilirsiniz (Bower ile ilgili olmasına rağmen, hemen hemen aynı durumdur). Ve Bower ana sayfasından ve Addy'nin makalesinden bir alıntıyla bitireceğim:

“Başkaları tarafından tüketilmesi amaçlanan bir paket yazmıyorsanız (örneğin, bir web uygulaması oluşturuyorsanız), yüklü paketleri her zaman kaynak kontrolünde kontrol etmelisiniz.”

Modüllerin detayları depolanır packages.json, bu yeterlidir. Check-in yapmaya gerek yok node_modules.

İnsanlar node_modulesmodül bağımlılıklarını kilitlemek için sürüm kontrolünde depolardı , ancak npm shrinkwrap ile artık gerekli değildir.

@ChrisCM'nin yorumda yazdığı gibi, bu nokta için başka bir gerekçe:

Ayrıca, yerel uzantıları içeren herhangi bir modül, mimariyi mimariye yansıtmayacak ve yeniden oluşturulması gerekecektir. Bunları repoya dahil ETMEMEK için somut gerekçe sağlamak.

PhantomJS ve node-sass gibi paketler nedeniyle, mevcut sistem için uygun ikiliyi yükleyen node_modules'de kontrol etmeyi öneriyorum .

Bu, bir Dev npm installLinux üzerinde çalışıyorsa ve node_modules'ü kontrol ederse, Windows'ta depoyu klonlayan başka bir Dev için işe yaramayacağı anlamına gelir .

Npm'in indirmeleri yükleyip npm-shrinkwrap.jsononlara işaret ettiği tarballları kontrol etmek daha iyidir . Shrinkpack kullanarak bu işlemi otomatikleştirebilirsiniz .

Bu konu oldukça eski, görüyorum. Ancak, npm'in eko sistemindeki durum nedeniyle burada sunulan argümanlarda bazı güncellemeler eksik.

Her zaman node_modules'ü sürüm kontrolü altına almamanızı tavsiye ederim. Kabul edilen cevap bağlamında listelendiği gibi bunu yapmanın neredeyse tüm faydaları şu an için oldukça eskidir.

1. Yayınlanan paketler artık kolayca npm kayıt defterinden iptal edilemez. Dolayısıyla, projenizin daha önce güvendiği bağımlılıkları kaybetmekten korkmanıza gerek yok.

2. Package-json.lock dosyasını VCS'ye koymak, muhtemelen aynı package.json dosyasına dayanarak farklı kurulumlara neden olan sık güncellenen bağımlılıklara yardımcı olur.

Dolayısıyla, çevrimdışı oluşturma araçlarına sahip olması durumunda node_modules'ü VCS'ye koymak, kalan tek uygun kullanım durumu olarak düşünülebilir. Bununla birlikte, node_modules genellikle oldukça hızlı büyür. Herhangi bir güncelleme çok sayıda dosyayı değiştirir. Ve bu havuzları farklı şekillerde etkiliyor. Uzun vadeli etkileri gerçekten düşünüyorsanız, bu da bir engel olabilir.

Merkezi VCS 'svn gibi, bir node_modules klasörünü kontrol etme veya güncelleme söz konusu olduğunda kararlı ve teslim alınmış dosyaların ağ üzerinden aktarılmasını gerektirir.

Git söz konusu olduğunda, bu yüksek sayıda ek dosya depoyu anında kirletecektir. Git'in herhangi bir dosyanın sürümleri arasındaki farkları izlemediğini, ancak tek bir karakter değiştiğinde dosyanın her iki sürümünün kopyalarını sakladığını unutmayın. Herhangi bir bağımlılığa yapılan her güncelleme başka bir büyük değişiklik kümesiyle sonuçlanacaktır. Git deponuz, yedeklemeleri ve uzaktan senkronizasyonu etkilediği için hızla büyüyecektir. Node_modules'ü git deposundan kaldırmaya karar verirseniz, daha sonra tarihsel nedenlerden dolayı hala bir parçasıdır. Git deponuzu bazı uzak sunuculara (örneğin yedekleme için) dağıtıyorsanız, temizlemek başka bir acı verici ve hataya açık görevdir.

Bu nedenle, verimli süreçlere önem veriyorsanız ve şeyleri "küçük" tutmak istiyorsanız, daha önce indirilmiş bazı bağımlılıklar kümesi sağlayan Nexos Deposu (veya yalnızca ZIP arşivleri olan bazı HTTP sunucuları) gibi ayrı bir yapay yapı deposu kullanmayı tercih ederim.

Değil izleme node_moduleskaynak kontrolü ile MongoDB NodeJS sürücü gibi bazı NodeJS modülleri, kullanım NodeJS C eklentileri ++ çünkü doğru seçimdir. Bu eklentiler npm installkomut çalıştırılırken derlenir . Bu nedenle, node_modulesdizini izlediğinizde, yanlışlıkla bir işletim sistemine özgü ikili dosya uygulayabilirsiniz.

İvoszz ile bazen node_modules klasörünü kontrol etmenin yararlı olduğunu kabul ediyorum , ancak ...

senaryo 1:

Bir senaryo: npm'den kaldırılan bir paket kullanıyorsunuz. Node_modules klasöründe tüm modüller varsa, bu sizin için sorun olmayacaktır. Package.json içinde sadece paket adı varsa, artık alamazsınız. Bir paket 24 saatten daha eski değilse, npm'den kolayca kaldırabilirsiniz. 24 saatten eskiyse onlarla iletişime geçmeniz gerekir. Fakat:

Desteğe başvurursanız, paketinizin bu sürümünü kaldırmanın diğer yüklemeleri bozup bozmayacağını kontrol ederler. Öyleyse, kaldırmayacağız.

daha fazla oku

Yani bunun şansı düşük, ancak 2. senaryo var ...

senaryo 2:

Durumun böyle olduğu başka bir senaryo: Yazılımınızın kurumsal bir sürümünü veya çok önemli bir yazılımı geliştiriyorsunuz ve paketinize yazıyorsunuz.

"dependencies": {
    "studpid-package": "~1.0.1"
}

Bu function1(x)paketin yöntemini kullanıyorsunuz .

Şimdi studpid-paketinin geliştiriciler yöntemini adlandırmak function1(x)için function2(x)ve onlar Onlar kendi paketinin sürümünü değiştirmek ... bir arıza yapmak 1.0.1için 1.1.0. Bu bir sorun çünkü bir npm installdahaki sefere 1.1.0aradığınızda, tilde ( "studpid-package": "~1.0.1") kullandığınız için sürümü kabul edeceksiniz .

Aramak function1(x)artık hatalara ve sorunlara neden olabilir.

Fakat:

Deponuza tüm node_modules klasörünü (genellikle 100 MB'den fazla) itmek, bellek alanınıza mal olur. Yüzlerce MB (package.json ve node_modules) ile karşılaştırıldığında birkaç kb (yalnızca package.json) ... Bir düşünün.

Bunu yapabilir / aşağıdaki durumlarda düşünmelisiniz :

• yazılım çok önemlidir.

• bir şey başarısız olduğunda size maliyet.

• npm kayıt defterine güvenmezsiniz. npm merkezileştirilmiştir ve teorik olarak kapatılabilir.

Sen gerekmez durumlarda ise 99.9% olarak klasör node_modules yayımlamak:

• sadece kendiniz için bir yazılım geliştirirsiniz.

• bir şey programladınız ve sonucu GitHub'da yayınlamak istiyorsunuz çünkü başka biri bununla ilgilenebilir.

Node_modules öğesinin deponuzda olmasını istemiyorsanız, bir .gitignoredosya oluşturun ve satırı ekleyin node_modules.

Yolun ortasına bir alternatif sunmak istiyorum.

1. node_modulesGit'e ekleme .
2. package-lock.jsonBağımlılık sürümlerinizi düzeltmek için bir dosya kullanın .
3. CI veya sürüm işleminizde, bir sürüm yayınladığınızda node_modules klasörünün bir kopyasını oluşturun ve yedekleyin (örneğin bulut depolama alanında).

NPM'ye (veya kullandığınız diğer kayıtlara) veya NPM'deki belirli bir pakete erişemediğiniz nadir durumlarda, node_modules'ün bir kopyasına sahip olursunuz ve erişimi geri yükleyene kadar çalışmaya devam edebilirsiniz.

Dikkate alınması gereken bir şey daha var: check-in ve node_modulesarasındaki farkı kullanmayı zor / imkansız hale getirir .dependenciesdevDependencies

Öte yandan, testlerden geçen aynı kodu üretime zorlamanın güven verici olduğunu söyleyebiliriz devDependencies.

package.json içinde bağımlılıklar belirtilmişse node_modules'ün check-in yapılması gerekmez. Başka herhangi bir programcı npm kurulumu yaparak bunu alabilir ve npm proje için çalışma dizinindeki node_modules yapmak için yeterince akıllıdır.