Apakah saya mengkomit file package-lock.json yang dibuat oleh npm 5?


1396

npm 5 dirilis hari ini dan salah satu fitur baru termasuk pemasangan deterministik dengan pembuatan package-lock.jsonfile.

Apakah file ini seharusnya disimpan dalam kendali sumber?

Saya berasumsi itu mirip dengan yarn.lockdan composer.lock, yang keduanya seharusnya disimpan dalam kontrol sumber.


20
Jawaban singkat: ya. Satu komentar: ketika package-lock.json berubah, Anda dapat membuat komit dari perubahan itu saja, terpisah dari perubahan sumber lainnya. Ini membuat git loglebih mudah untuk ditangani.
Purplejacket

14
File tidak dapat membantu menghasilkan instalasi deterministik jika tidak ada.
Alan H.

4
Tergantung pada proyek. github.com/npm/npm/issues/20603
Gajus

3
Jika Anda benar-benar percaya npm yakin, tujuannya adalah untuk lebih eksplisit melaporkan apa yang digunakan proyek. Jika Anda benar-benar ingin prediktabilitas, abaikan file ini dan sebaliknya instal node_modules Anda (lihat .npmrc dan konfigurasi terkait di jawaban + komentar) dan gunakan itu untuk melacak apa yang sebenarnya berubah daripada apa yang dikatakan oleh manajer paket Anda. Pada akhirnya: yang lebih penting? Manajer paket Anda atau kode yang Anda gunakan.
Jimmont

Jawaban:


1617

Ya, package-lock.jsondimaksudkan untuk diperiksa ke dalam kontrol sumber. Jika Anda menggunakan npm 5, Anda dapat melihat ini di baris perintah: created a lockfile as package-lock.json. You should commit this file.Menurut npm help package-lock.json:

package-lock.jsonsecara otomatis dihasilkan untuk operasi apa pun di mana npm memodifikasi node_modulespohon, atau package.json. Ini menjelaskan pohon persis yang dihasilkan, sehingga instalasi berikutnya dapat menghasilkan pohon yang identik, terlepas dari pembaruan ketergantungan menengah.

File ini dimaksudkan untuk dijadikan repositori sumber , dan melayani berbagai tujuan:

  • Jelaskan representasi tunggal dari pohon dependensi sehingga rekan tim, penyebaran, dan integrasi berkelanjutan dijamin untuk menginstal dependensi yang persis sama.

  • Menyediakan fasilitas bagi pengguna untuk "perjalanan waktu" ke keadaan sebelumnya node_modulestanpa harus melakukan direktori itu sendiri.

  • Untuk memfasilitasi visibilitas perubahan pohon yang lebih besar melalui perbedaan kontrol sumber yang dapat dibaca.

  • Dan optimalkan proses instalasi dengan memungkinkan npm untuk melewati resolusi metadata berulang untuk paket yang sebelumnya diinstal.

Salah satu detail utama package-lock.jsonadalah tidak dapat dipublikasikan, dan akan diabaikan jika ditemukan di tempat lain selain paket tingkat atas. Ini berbagi format dengan npm-shrinkwrap.json (5), yang pada dasarnya adalah file yang sama, tetapi memungkinkan publikasi. Ini tidak disarankan kecuali menggunakan alat CLI atau menggunakan proses publikasi untuk memproduksi paket produksi.

Jika keduanya package-lock.jsondan npm-shrinkwrap.jsonhadir di root paket, package-lock.jsonakan sepenuhnya diabaikan.


77
Dalam proyek seperti apa sebenarnya membantu untuk melakukan file? Inti dari semver dan package.json adalah bahwa dependensi yang kompatibel yang diperbarui tidak perlu dicatat.
curiousdannii

45
Kata kuncinya adalah "seharusnya tidak perlu" - tetapi dalam praktiknya orang tidak mengikuti semver dengan sempurna. Itu sebabnya Anda bisa menggunakan package-lock.json dan package.json bersama-sama untuk memudahkan memperbarui paket tetapi masih memastikan setiap pengembang dan setiap aplikasi yang digunakan menggunakan pohon dependensi yang sama.
Panu Horsmalahti

34
@trusktr: Sindre Sorhus merekomendasikan penggunaan "Lockfiles untuk aplikasi, tetapi tidak untuk paket."
vine77

23
Hal lain adalah, package-lock.json diabaikan untuk penerbitan di NPM, jadi jika pengembang menggunakannya untuk pengembang perpustakaan, maka mereka meminimalkan kemungkinan bahwa mereka akan menangkap regresi dari versi dependensi yang diperbarui, dan karena itu akan melewati itu bug ke pengguna akhir. Karena alasan ini, tidak menggunakan file kunci untuk perpustakaan dev meningkatkan kemungkinan pengiriman lebih sedikit bug.
trusktr

128
Secara pribadi saya sekarang harus terpaksa menambahkan package-lock.jsonke .gitignore... itu menyebabkan saya lebih banyak masalah daripada menyelesaikannya. Itu selalu konflik ketika kita menggabungkan atau rebase, dan ketika suatu hasil gabungan package-lock.jsonmenjadi rusak di server CI, itu hanya sakit harus tetap memperbaikinya.
Stefan Z Camilleri

111

Ya, ini dimaksudkan untuk check-in. Saya ingin menyarankan agar ia mendapatkan komit uniknya sendiri. Kami menemukan bahwa itu menambahkan banyak suara ke diff kami.


19
itu adil untuk diperdebatkan apakah harus diperiksa ke dalam repositori kode sumber Anda, tetapi menerbitkan file ini ke npm tidak benar-benar cocok untuk diperdebatkan - Anda harus memasukkan paket-lock.json Anda atau file shrinkwrap Anda ke dalam registri npm Anda. jika tidak, paket Anda yang diterbitkan akan mengalami perubahan dependensi tak berpasangan dari dependensi generasi pertama Anda. Anda tidak akan melihat ini menjadi masalah sampai salah satu dari dependensi generasi ke-2 + menerbitkan perubahan yang melanggar, dan paket Anda yang diterbitkan menjadi rusak secara misterius. file package-lock.json ini dibuat untuk mengatasi masalah itu.
guerillapresident

9
@BetoAveiga oleh noise Maksud saya komit dengan package-lock.json dapat memiliki banyak baris versi paket node, sehingga semua pekerjaan lain dalam komit tersebut menjadi tersembunyi.
xer0x

7
Saya biasanya menjaga instalasi paket terpisah dari pekerjaan lain. Saya tidak perlu membedakan komit seperti "Chai dan mocha Terpasang", karena saya sudah tahu apa yang berubah.
Keith

3
Adakah saran mengenai package-lock.jsonfile saat bekerja pada sistem SCM dengan batang dan percabangan? Saya membuat beberapa perubahan pada cabang yang perlu digabungkan ke trunk ... apakah sekarang saya harus (entah bagaimana) menyelesaikan konflik antara kedua package-lock.jsonfile? Ini terasa menyakitkan.
kmiklas

3
@guerillapresident Seperti yang saya pahami, Anda sebagian benar. Menerbitkan file ini ke npm tidak dapat diperdebatkan. Anda tidak dapat mempublikasikannya.
Tim Gautier

66

Ya kamu harus:

  1. melakukan package-lock.json.
  2. gunakan npm cibukannyanpm install saat membangun aplikasi Anda baik pada CI Anda dan mesin pengembangan lokal Anda

The npm cialur kerja membutuhkan adanya package-lock.json.


Kelemahan besar dari npm installperintah adalah perilaku tak terduga yang dapat dimutasikannya package-lock.json, sedangkan npm cihanya menggunakan versi yang ditentukan dalam file kunci dan menghasilkan kesalahan

  • jika package-lock.jsondanpackage.json tidak sinkron
  • jika ada package-lock.jsonyang hilang.

Oleh karena itu, berjalan npm installsecara lokal, esp. di tim yang lebih besar dengan banyak pengembang, dapat menyebabkan banyak konflik di dalam package-lock.jsondan pengembang memutuskan untuk sepenuhnya menghapuspackage-lock.json .

Namun ada kasus penggunaan yang kuat untuk bisa percaya bahwa ketergantungan proyek diselesaikan berulang-ulang dengan cara yang dapat diandalkan di berbagai mesin.

Dari package-lock.json Anda mendapatkan hal itu: suatu kondisi yang diketahui bekerja.

Di masa lalu, saya punya proyek tanpa package-lock.json/ npm-shrinkwrap.json/yarn.lock file yang membangun suatu hari akan gagal karena ketergantungan acak mendapat pembaruan yang melanggar.

Masalah itu sulit untuk dipecahkan karena terkadang Anda harus menebak versi terakhir yang berfungsi.

Jika Anda ingin menambahkan ketergantungan baru, Anda masih menjalankan npm install {dependency}. Jika Anda ingin meng-upgrade, menggunakan baik npm update {dependency}atau npm install ${dependendency}@{version}dan komit berubah package-lock.json.

Jika pemutakhiran gagal, Anda dapat kembali ke pekerjaan yang terakhir diketahui package-lock.json.


Untuk mengutip doc NPM :

Sangat disarankan Anda melakukan kunci paket yang dihasilkan untuk kontrol sumber: ini akan memungkinkan orang lain di tim Anda, penyebaran Anda, CI Anda / integrasi terus menerus, dan siapa pun yang menjalankan npm menginstal di sumber paket Anda untuk mendapatkan pohon ketergantungan yang sama persis yang sedang Anda kembangkan. Selain itu, perbedaan dari perubahan ini dapat dibaca oleh manusia dan akan memberi tahu Anda setiap perubahan yang telah dilakukan npm ke node_modules Anda, sehingga Anda dapat melihat apakah ada dependensi transitif yang diperbarui, diangkat, dll.

Dan dalam hal perbedaan antara npm civsnpm install :

  • Proyek harus memiliki package-lock.json atau npm-shrinkwrap.json.
  • Jika dependensi dalam kunci paket tidak cocok dengan yang ada di package.json, npm ci akan keluar dengan kesalahan, alih-alih memperbarui kunci paket.
  • npm ci hanya dapat menginstal seluruh proyek sekaligus: dependensi individual tidak dapat ditambahkan dengan perintah ini.
  • Jika a node_modulessudah ada, maka akan dihapus secara otomatis sebelum npm cimemulai pemasangannya.
  • Itu tidak akan pernah menulis package.jsonatau salah satu dari kunci-paket: instalasi pada dasarnya beku.

Catatan: Saya mengirim jawaban serupa di sini


10
Jawaban ini layak mendapat kredit lebih, terutama menggunakan npm ci. Menggunakan ini mengurangi sebagian besar masalah yang dialami orang dengan kunci paket.
JamesB

Saya telah menemukan menggunakan versi tetap di package.json (tidak ada tanda sisipan atau tilde) menjadi pilihan yang jauh lebih bersih. Ini menyelamatkan saya dari whose build would fail one day because a random dependency got a breaking updatemasalah. Meskipun itu meninggalkan kemungkinan ketergantungan anak karena masalah yang sama.
Ashwani Agarwal

58

Ya, praktik terbaik adalah check-in (YA, LIHAT-IN)

Saya setuju bahwa itu akan menyebabkan banyak kebisingan atau konflik ketika melihat diff. Tetapi manfaatnya adalah:

  1. menjamin versi yang sama persis dari setiap paket . Bagian ini adalah yang paling penting ketika membangun di lingkungan yang berbeda pada waktu yang berbeda. Anda dapat menggunakan ^1.2.3di package.json, tetapi bagaimana Anda bisa memastikan setiap kali npm installakan mengambil versi yang sama di mesin dev Anda dan di server build, terutama paket dependensi tidak langsung? Nah, package-lock.jsonakan memastikan itu. (Dengan bantuan npm ciyang menginstal paket berdasarkan file kunci)
  2. itu meningkatkan proses instalasi.
  3. ini membantu dengan fitur audit baru npm audit fix(saya pikir fitur audit berasal dari npm versi 6).

3
Sejauh yang saya tahu, tidak pernah menggunakan semver (yang npm devs tidak mengerti juga) harus menghasilkan perilaku yang sama seperti memiliki file kunci setidaknya dalam 99% kasus. Pengalaman saya sendiri adalah bahwa semver fuckups sebagian besar terjadi dengan paket primer (dependensi langsung, datepickers jquery jelek, dll). Pengalaman pribadi saya dengan npm adalah bahwa file kunci tidak berisik selamanya. Saya harap kebijaksanaan ini tidak berubah dengan versi terbaru.
Svend

13
+1 untuk disebutkan npm ci. Orang-orang sering menyebutkan bahwa a package-lock.jsonmengijinkan instalasi paket yang deterministik tetapi hampir tidak pernah menyebutkan perintah yang memfasilitasi perilaku ini! Banyak orang mungkin salah mengira npm installmenginstal persis apa yang ada dalam file kunci ...
ahaurat

npm ci tidak ada di npm 5.
dpurrington

Terima kasih! Masuk akal untuk melakukan package-lock.json jika Anda menggunakan npm ci. Pengembang tim / pemimpin Anda dapat memutuskan kapan akan memperbarui. Jika semua orang melakukannya secara sewenang-wenang, tidak ada gunanya, dan itu hanya membuat suara di repo Anda. Dokumentasi NPM harus membuatnya lebih jelas. Saya pikir sebagian besar pengembang hanya bingung dengan fitur ini.
adampasz

@adampasz sebenarnya masing-masing dev dapat melakukan file kunci, dan setelah lulus pengujian dan digabung, cabang kedua hanya memperbarui file kunci jika entah bagaimana paket-paketnya diubah (kami tidak mengubah paket. sering, kita kurang menghadapi masalah ini (
Xin

38

Saya tidak melakukan file ini di proyek saya. Apa gunanya ?

  1. Itu dihasilkan
  2. Ini adalah penyebab kesalahan kode SHA1 di gitlab dengan build gitlab-ci.yml

Meskipun benar bahwa saya tidak pernah menggunakan ^ dalam paket saya. Json for libs karena saya memiliki pengalaman buruk dengannya.


11
Saya berharap ini bisa dijelaskan lebih lanjut dari dalam npm docs - Ini akan berguna untuk memiliki garis besar tentang apa yang Anda kehilangan secara spesifik dengan tidak melakukan package-lock.json. Beberapa repo mungkin tidak memerlukan manfaat yang berasal dari memilikinya, dan mungkin lebih suka tidak memiliki konten yang dibuat secara otomatis di sumbernya.
PotatoFarmer

2
Saya dapat melihat bagaimana ini berguna untuk debugging (perbedaan antara dua kunci misalnya) untuk membantu menyelesaikan masalah. Saya kira itu juga dapat digunakan untuk mencegah hal-hal semacam ini tetapi juga bisa menyusahkan dalam repo bersama di mana ia mungkin mengalami konflik gabungan karenanya. Sebagai permulaan saya ingin menjaga hal-hal sederhana, saya hanya akan menggunakan package.json sendiri sampai saya melihat ada kebutuhan nyata untuk package-lock.json.
radtek

6
Anda mungkin tidak menggunakan ^ di package.json Anda, tetapi Anda dapat memastikan dependensi Anda tidak menggunakannya?
neiker

35

Untuk orang-orang yang mengeluh tentang kebisingan ketika melakukan git diff:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

Apa yang saya lakukan adalah menggunakan alias:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Untuk mengabaikan package-lock.json di diffs untuk seluruh repositori (semua orang menggunakannya), Anda dapat menambahkan ini ke .gitattributes:

package-lock.json binary
yarn.lock binary

Ini akan menghasilkan perbedaan yang menunjukkan "File biner a / package-lock.json dan b / package-lock.json berbeda setiap kali file kunci paket diubah. Selain itu, beberapa layanan Git (terutama GitLab, tetapi bukan GitHub) juga akan mengecualikan file-file ini (tidak ada lagi baris 10k berubah!) dari diff saat melihat online ketika melakukan ini.


1
Saya miliki gd() { git diff --color-words $1 $2 -- :!/yarn.lock :!/package-lock.json; }di .bashrc saya, bukan alias.
apostl3pol

16

Ya, Anda dapat melakukan file ini. Dari dokumen resmi npm :

package-lock.jsonsecara otomatis dihasilkan untuk operasi apa pun di mana npmmemodifikasi node_modulespohon, ataupackage.json . Ini menjelaskan pohon persis yang dihasilkan, sehingga instalasi berikutnya dapat menghasilkan pohon yang identik, terlepas dari pembaruan ketergantungan menengah.

File ini dimaksudkan untuk dimasukkan ke dalam repositori sumber [.]


13
Bukankah instalasi selalu memperbarui node_modules, dan karenanya memperbarui paket-lock.json?
Tim Gautier

2
Tidak, Anda dapat menjalankan npm ciuntuk menginstal dari package-lock.json
William Hampshire

Anda perlu menekankan dalam jawaban Anda bahwa Anda HARUS menggunakan npm ci dalam membangun integrasi berkelanjutan Anda jika Anda memiliki package-lock.json pada repo
MagicLAMP

6

Nonaktifkan package-lock.json secara global

ketikkan yang berikut ini di terminal Anda:

npm config set package-lock false

ini benar-benar bekerja untuk saya seperti sulap


2
ini menciptakan ~/.npmrc(setidaknya di makro saya) dengan konten package-lock=falsedan hal yang sama dapat dilakukan dalam proyek spesifik bersama node_modules/(misalnyaecho 'package-lock=false' >> .npmrc
jimmont

6
agak lucu bagi saya bahwa ini akan menjadi negatif. komunitas npm tidak dapat menerima bahwa paket-lock.json otomatis menghasilkan keterlibatan masyarakat yang buruk. Anda tidak harus melakukan hal-hal yang dapat memengaruhi proses tim. seharusnya pilihan untuk mengaktifkan, tidak dipaksa. berapa banyak orang yang melakukan "git add *" dan bahkan tidak menyadarinya dan mengacaukan build. Jika Anda memiliki aliran berbasis penggabungan, saya tahu aliran git seperti Alkitab bagi orang yang menggunakannya, ini tidak akan berhasil. Anda tidak dapat memiliki generasi yang bergabung! versi npm rusak, paket: 1.0.0 harus deterministik!
Eric Twilegar

3
mengapa ini dipilih? ini jelas merupakan cara yang sah untuk menonaktifkan fitur yang tidak berfungsi. Dan meskipun itu tidak menjawab pertanyaan itu sendiri, ia mempermasalahkan pertanyaan itu. yaitu tidak perlu lagi dijawab. Jempol dari saya :)
Superole

Alasan mengapa itu downvoted adalah karena Anda hanya menonaktifkan fitur.
Raza

5

Ya, ini adalah praktik standar untuk melakukan package-lock.json

Alasan utama untuk melakukan package-lock.json adalah bahwa semua orang dalam proyek ini pada versi paket yang sama.

Pro: -

  • Jika Anda mengikuti versi ketat dan tidak mengizinkan memperbarui ke versi utama secara otomatis untuk menyelamatkan diri Anda dari perubahan mundur yang tidak kompatibel dalam paket pihak ketiga melakukan penguncian paket sangat membantu.
  • Jika Anda memperbarui paket tertentu, itu akan diperbarui di package-lock.json dan semua orang yang menggunakan repositori akan diperbarui ke versi tertentu ketika mereka mengambil perubahan Anda.

Kekurangan: -

  • Itu dapat membuat permintaan tarik Anda terlihat jelek :) '

Sunting: - instalasi npm tidak akan memastikan bahwa semua orang dalam proyek ini pada versi paket yang sama. npm ci akan membantu dengan ini.


4
Kontra akan pergi jika Anda akan menggunakan npm cibukan npm install.
k0pernikus


1
"Semua orang dalam proyek ini akan berada pada versi paket yang sama, yang harus Anda lakukan adalah menginstal npm" Tidak benar, Anda perlu menggunakan "npm ci" sebagai gantinya
reggaeguitar

Terima kasih, @reggaeguitar. Memperbarui jawaban saya untuk ini.
Nikhil Mohadikar

2

Penggunaan npm saya adalah untuk menghasilkan css / js minified / uglified dan untuk menghasilkan javascript yang dibutuhkan dalam halaman yang dilayani oleh aplikasi Django. Dalam aplikasi saya, Javascript berjalan pada halaman untuk membuat animasi, beberapa kali melakukan panggilan ajax, bekerja dalam kerangka VUE dan / atau bekerja dengan css. Jika package-lock.json memiliki kontrol utama atas apa yang ada di package.json, maka mungkin perlu ada satu versi file ini. Dalam pengalaman saya, itu tidak mempengaruhi apa yang diinstal oleh npm install, atau jika ya, itu tidak sampai saat ini mempengaruhi aplikasi yang saya sebarkan dengan sepengetahuan saya. Saya tidak menggunakan mongodb atau aplikasi lain yang biasanya merupakan klien tipis.

Saya menghapus package-lock.json dari repo karena npm install menghasilkan file ini, dan install npm adalah bagian dari proses penyebaran pada setiap server yang menjalankan aplikasi. Kontrol versi node dan npm dilakukan secara manual pada setiap server, tetapi saya berhati-hati karena keduanya sama.

Ketika npm installdijalankan di server, itu mengubah package-lock.json, dan jika ada perubahan pada file yang direkam oleh repo di server, penyebaran berikutnya WONT memungkinkan Anda untuk menarik perubahan baru dari asal. Itu adalah Anda tidak dapat menyebarkan karena tarikan akan menimpa perubahan yang telah dibuat untuk package-lock.json.

Anda bahkan tidak dapat menimpa paket-lock.json yang dibuat secara lokal dengan apa yang ada di repo (reset master asal keras), karena npm akan mengeluh kapan pun Anda mengeluarkan perintah jika package-lock.json tidak mencerminkan apa yang ada di dalam node_modules karena npm instal, sehingga melanggar penyebaran. Sekarang jika ini menunjukkan bahwa versi yang sedikit berbeda telah diinstal di node_modules, sekali lagi itu tidak pernah menyebabkan masalah bagi saya.

Jika node_modules tidak ada di repo Anda (dan seharusnya tidak), maka package-lock.json harus diabaikan.

Jika saya kehilangan sesuatu, perbaiki saya di komentar, tetapi poin bahwa versi diambil dari file ini tidak masuk akal. File package.json memiliki nomor versi di dalamnya, dan saya berasumsi file ini adalah yang digunakan untuk membangun paket ketika instalasi npm terjadi, seperti ketika saya menghapusnya, instal npm mengeluh sebagai berikut:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

dan build gagal, namun ketika menginstal node_modules atau menerapkan npm untuk membangun js / css, tidak ada keluhan dibuat jika saya menghapus package-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...

Hanya untuk menambahkan, saya sekarang telah melakukan package-lock.json saya ke repositori saya, dan saya menggunakan npm ci pada penyebaran saya yang mungkin, yang saya yakin akan menghapus node_modules, dan menginstal semuanya di package-lock.json tanpa memperbaruinya. Hal ini memungkinkan orang ujung depan saya untuk meningkatkan hal-hal javascript tanpa perlu intervensi manual dalam menyebarkan.
MagicLAMP
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.