Bukan ini yang dimaksudkan untuk dilakukan oleh ci / cleaninstall. Perilaku saat ini benar. Yang ingin Anda gunakan adalah npm shrinkwrap .

Kami menambahkan pembaruan untuk menghindari penghapusan node_modules _folder_ tetapi bukan _contents_ (seperti yang awalnya diminta pada posting itu). Tujuan perintah npm ci adalah untuk menghapus semuanya dari awal yang bersih. Jika Anda ingin mempertahankan node_modules lama Anda, yang Anda butuhkan adalah npm i .

Terima kasih atas balasan Anda! Maaf untuk keterlambatan jawaban saya. Saya telah melihat npm shrinkwrap tetapi apakah ini dimaksudkan untuk berjalan di server build kami untuk integrasi berkelanjutan? Saat menjalankan perintah ini, ia mengganti nama package-lock.json menjadi npm-shrinkwrap.json tetapi apa yang harus saya jalankan selama CI? Hanya npm install untuk mendapatkan pembaruan tambahan? Atau haruskah saya menjalankan npm ci tetapi itu akan menghapus semua paket lagi :-( Yang saya cari adalah perintah yang melakukan pembaruan tambahan tetapi akan menginstal persis apa yang ada di package-lock.json

@claudiahdz; Pemahaman saya adalah bahwa menjalankan npm install selama CI akan memperbarui package-lock.json dan itu bisa berarti bahwa menjalankan build yang sama beberapa minggu kemudian akan menginstal paket yang berbeda. Apakah itu salah?

Ps Saya pikir npm ci adalah kependekan dari Continuous Integration

Seperti yang dirujuk di sini: https://github.com/npm/npm/issues/20104#issuecomment -403321557

Perilaku saat ini bermasalah jika Anda menggunakan npm ci di dalam wadah Docker (yang cukup umum untuk Integrasi Berkelanjutan) dan Anda memiliki pengikatan pada node_modules

Ini menyebabkan kesalahan berikut:

webpack_1   | npm ERR! path /var/www/project/docker-config/webpack-dev-devmode/node_modules
webpack_1   | npm ERR! code EBUSY
webpack_1   | npm ERR! errno -16
webpack_1   | npm ERR! syscall rmdir
webpack_1   | npm ERR! EBUSY: resource busy or locked, rmdir '/var/www/project/docker-config/webpack-dev-devmode/node_modules'

yang kemudian menghasilkan pembatalan wadah Docker.

Akan menyenangkan untuk memiliki flag --no-delete atau jika npm ci dapat menghapus _contents_ dari node_modules tetapi bukan direktori itu sendiri.

ci = instalasi bersih

Ini diharapkan. Mengapa Anda tidak menggunakan npm i normal dengan file kunci?

Akan menyenangkan memiliki flag --no-delete atau jika npm ci dapat menghapus konten node_modules tetapi bukan direktori itu sendiri.

rm -rf node_modules/* && npm i

ci = instalasi bersih

Ini diharapkan. Mengapa Anda tidak menggunakan npm i normal dengan file kunci?

...karena: https://docs.npmjs.com/cli/ci.html

Perintah ini mirip dengan npm-install, kecuali itu dimaksudkan untuk digunakan di lingkungan otomatis seperti platform pengujian, integrasi berkelanjutan , dan penerapan – atau situasi apa pun di mana Anda ingin memastikan bahwa Anda melakukan instalasi dependensi yang bersih. Ini bisa jauh lebih cepat daripada instalasi npm biasa dengan melewatkan fitur berorientasi pengguna tertentu. Ini juga lebih ketat daripada instalasi biasa, yang dapat membantu menangkap kesalahan atau inkonsistensi yang disebabkan oleh lingkungan lokal yang diinstal secara bertahap dari sebagian besar pengguna npm.

Penginstalan yang lebih cepat dan pendekatan clean slate membuat ini ideal untuk lingkungan CI seperti yang saya sebutkan di atas.

rm -rf node_modules/* && npm i

Inilah yang saya lakukan sekarang, tetapi lihat di atas keinginan untuk menggunakan npm ci

Tampaknya masuk akal bagi saya untuk mengajukan RFC yang meminta flag konfigurasi yang membuat npm ci menghapus konten node_modules dan bukan direktori itu sendiri. Ini juga merupakan masalah bagi saya, karena saya telah menyiapkan Dropbox untuk secara selektif mengabaikan dir node_modules , tetapi jika saya menghapusnya, pengaturan selektif itu hilang, dan lain kali node_modules dibuat, itu disinkronkan.

Tampaknya masuk akal bagi saya untuk mengajukan RFC yang meminta flag konfigurasi yang membuat npm ci menghapus _contents_ dari node_modules dan bukan direktori itu sendiri. Ini juga merupakan masalah bagi saya, karena saya telah menyiapkan Dropbox untuk secara selektif mengabaikan dir node_modules , tetapi jika saya menghapusnya, pengaturan selektif itu hilang, dan lain kali node_modules dibuat, itu disinkronkan.

Bukankah ini juga yang dijelaskan oleh masalah lain, untuk memungkinkan npm membuat file untuk mengabaikan dir (untuk sorotan OSX dan lainnya)? Saya pikir ada juga orang lain yang membutuhkan fitur ini.

ci = instalasi bersih

Ini diharapkan. Mengapa Anda tidak menggunakan npm i normal dengan file kunci?

npm i akan sangat bagus tetapi hanya jika itu tidak akan mengubah file kunci. Saya telah melihat package-lock.json telah diperbarui selama npm i atau seharusnya itu tidak terjadi?

Saya mendukung fitur ini. Seperti yang dinyatakan, npm i memodifikasi package-lock.json. Bendera akan menjadi solusi ideal.

sama, bendera akan bagus

Saya mendukung fitur ini. Seperti yang dinyatakan, npm i memodifikasi package-lock.json. Bendera akan menjadi solusi ideal.

Mengapa tidak menambahkan bendera untuk npm i ? Karena ini tidak masuk akal untuk ci = clean install menurut saya.

Bagian mana dari "instalasi bersih" yang tidak kompatibel dengan menjaga direktori induk node_modules/ tetap utuh (saat melakukan instalasi bersih dari konten aktual)?

Saya menyadari bahwa CI tidak berdiri untuk Integrasi Berkelanjutan dalam kasus ini; tetapi Instalasi Bersih seringkali cukup berguna dalam lingkungan Integrasi Berkelanjutan, seperti yang dijelaskan oleh dokumentasi.

Perintah ini mirip dengan npm-install, kecuali itu dimaksudkan untuk digunakan di lingkungan otomatis seperti platform pengujian, integrasi berkelanjutan, dan penerapan – atau situasi apa pun di mana Anda ingin memastikan bahwa Anda melakukan instalasi dependensi yang bersih. Ini bisa jauh lebih cepat daripada instalasi npm biasa dengan melewatkan fitur berorientasi pengguna tertentu. Ini juga lebih ketat daripada instalasi biasa, yang dapat membantu menangkap kesalahan atau inkonsistensi yang disebabkan oleh lingkungan lokal yang diinstal secara bertahap dari sebagian besar pengguna npm.

npm ci secara khusus dimaksudkan untuk digunakan di lingkungan otomatis, sering kali ini berarti pengaturan berbasis Docker.

Perilaku menghapus direktori node_module/ merepotkan dalam pengaturan berbasis Docker, karena alasan yang disebutkan di utas ini.

Jadi kami meminta opsi yang akan membuat perintah ini berguna untuk tujuan dan lingkungan yang dimaksudkan.

Saya mendukung fitur ini. Seperti yang dinyatakan, npm i memodifikasi package-lock.json. Bendera akan menjadi solusi ideal.

Mengapa tidak menambahkan bendera untuk npm i ? Karena ini tidak masuk akal untuk ci = clean install menurut saya.

Saya harus mengajukan pertanyaan ini apakah ada perbedaan lain antara npm install dan npm ci jika tidak maka mengapa kedua opsi tidak tersedia di npm install mungkin ci perlu menjadi beberapa alias seperti npm install --no-update-package-lock --clean-node-modules

Perilaku menghapus direktori node_module/ merepotkan dalam pengaturan berbasis Docker, karena alasan yang disebutkan di utas ini.

Menurut pendapat saya, ini seharusnya hanya terjadi sekali ketika gambar dibuat. Setelah itu npm i harus digunakan selama pengembangan.

mungkin ci perlu menjadi beberapa alias seperti npm install --no-update-package-lock --clean-node-modules

Secara pribadi itu lebih masuk akal bagi saya, tanda tambahan untuk perintah npm i normal.

Saya tidak peduli yang mana, dan sejujurnya terlalu banyak n00b dengan js land untuk memiliki argumen konkret bahwa itu harus ci , yang saya tahu adalah bahwa itu tidak boleh memperbarui package-lock.json dan seharusnya tidak menghapus node_modules

npm ci tidak memperbarui lockfile, ia menginstal dari lockfile. Ini diperkenalkan untuk melakukan instalasi bersih karena sebelumnya orang ini disarankan untuk rm -rf node_modules dan menjalankan npm i lagi. Dan orang afaik ingin itu tidak mengubah file kunci tetapi menginstal darinya.

Jadi npm ci lahir. Dan itu juga melewatkan beberapa hal seperti daftar paket yang diinstal dan pohon dan beberapa hal lagi.

Lihat https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

Ini mencakup kasus penggunaan tertentu.

Untuk kasus penggunaan lain, kita harus menambahkan flag baru ke npm i yang dengannya kita juga dapat meniru npm ci yang merupakan solusi yang lebih fleksibel dan lebih baik daripada flag untuk npm ci yang seharusnya masih mencakup saja kasus penggunaan saat ini imho. Apa yang diminta pengguna di sini agak mirip dengan yarn install --frozen-lockfile atau yarn --frozen-lockfile .

Kalau tidak, bendera tersebar di npm ci , npm i dan seterusnya yang membuatnya sedikit lebih sulit (dokumentasi, kode, ...). Setidaknya ini menurut saya. Mari kita ke npm i t memiliki cara yang lebih kuat dan fleksibel untuk mengkonfigurasi perilakunya.

Untuk kasus penggunaan lain, kita harus menambahkan flag baru ke npm idengan mana kita juga dapat meniru npm ci yang merupakan solusi yang lebih fleksibel dan lebih baik daripada flag untuk npm ci yang masih harus mencakup hanya kasus penggunaan saat ini imho. Apa yang diminta pengguna di sini agak mirip dengan yarn install --frozen-lockfile atau yarn --frozen-lockfile.

Saya akan sangat senang jika fitur tersebut ditambahkan ke npm i . Haruskah saya memperbarui posting asli?

npm ci tidak memperbarui lockfile, ia menginstal dari lockfile. Ini diperkenalkan untuk melakukan instalasi bersih karena sebelumnya orang ini disarankan untuk rm -rf node_modules dan menjalankan npm i lagi. Dan orang afaik ingin itu tidak mengubah file kunci tetapi menginstal darinya.

Jadi npm ci lahir. Dan itu juga melewatkan beberapa hal seperti daftar paket yang diinstal dan pohon dan beberapa hal lagi.

Lihat https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

Ini mencakup kasus penggunaan tertentu.

Untuk kasus penggunaan lain, kita harus menambahkan flag baru ke npm i yang dengannya kita juga dapat meniru npm ci yang merupakan solusi yang lebih fleksibel dan lebih baik daripada flag untuk npm ci yang seharusnya masih mencakup saja kasus penggunaan saat ini imho. Apa yang diminta pengguna di sini agak mirip dengan yarn install --frozen-lockfile atau yarn --frozen-lockfile .

Bagaimana rm -rf node_modules/* tidak memenuhi syarat sebagai "pembersihan" ? Fitur yang ditanyakan di sini sangat mirip dengan yang ada di npm ci. Menurut pendapat saya, lebih masuk akal untuk menambahkan flag ke npm ci sehingga menggunakan rm -rf node_modules/* daripada rm -rf node_modules daripada mengimpor seluruh perilaku npm ci ke npm i.

BTW masalah ini harus mendapat perhatian lebih dan pengelola harus menyuarakan pendapat dan rencana mereka tentang itu, menggunakan buruh pelabuhan pada dasarnya selalu digunakan dalam CI (integrasi berkelanjutan) yang merupakan salah satu kasus penggunaan utama npm ci !

Silakan buka RFC untuk perubahan ini, bukan masalah di repo ini.

Untuk menghindari kebingungan, saya akan mengganti nama masalah ini sebagai "kosong alih-alih menghapus node_modules dir di npm CI"

Maksud saya dari masalah ini adalah tidak pernah menghapus folder node_modules atau hanya isinya. Itu selalu untuk mempertahankan konten node_modules tetapi pastikan itu mutakhir dan sinkron dengan package-lock.json . Jadi pembaruan tambahan yang mematuhi package-lock.json .

Mungkin saya salah tetapi saya merasa ada dua masalah di sini. Mungkin seseorang dapat memulai masalah lain atau RFC tentang menghapus hanya konten node_modules alih-alih menghapus folder sepenuhnya? Atau apakah saya melewatkan sesuatu?

@Zenuka seluruh alasan npm CI cepat, dan ada, adalah karena mengabaikan dir node_modules yang ada, jadi sangat tidak mungkin itu akan berubah.

Dalam kasus penggunaan kami, saya pikir akan lebih cepat hanya untuk memeriksa apakah folder nodes_modules sudah diperbarui atau tidak. Dan jika tidak, hanya perbarui paket yang harus diperbarui (seperti yang dilakukan npm i ) Saya memiliki beberapa VM khusus yang berjalan sebagai agen build sehingga menjalankan build dan menyimpan folder nodes_modules dan semua isinya harus lebih cepat daripada menghapus semuanya dan menginstalnya kembali. Kami menjalankan build dan pengujian kami untuk perubahan kode lebih banyak daripada perubahan pada package.json atau package-lock.json .

Dalam kasus penggunaan kami, saya pikir akan lebih cepat hanya untuk memeriksa apakah folder nodes_modules sudah diperbarui atau tidak.

Nah, ini (perhitungan package tree) yang paling memakan waktu. Pemeriksaan ini akan membuat npm ci sangat lambat.

menjalankan build dan menyimpan folder nodes_modules dan semua isinya harus lebih cepat daripada menghapus semuanya dan menginstal ulang.

Mungkin tidak, itu sebabnya npm ci diperkenalkan yang melompati apa yang dilakukan npm i (periksa pohon paket).

@Zenuka npm install sudah merupakan cara tercepat untuk melakukan apa yang Anda inginkan. npm ci hanya memiliki satu tujuan: melakukannya lebih cepat, dengan menghapus node_modules sehingga tidak perlu menghitung diff.

Mungkin tidak, itu sebabnya npm ci diperkenalkan yang melewatkan apa yang npm saya lakukan (periksa pohon paket).

Saya telah menguji ini hanya di mesin saya (yang tentu saja bukan ukuran yang baik) tetapi menjalankan npm install pada folder node_modules selesai dalam 10 detik. Menjalankan npm ci membutuhkan waktu beberapa menit. Apakah Anda mengharapkan hasil yang berbeda?

Saya penggemar saran Anda untuk menambahkan tanda untuk membekukan file kunci dengan npm install .

Memverifikasi bahwa apa yang ada di package-lock.json benar-benar ada sangat cepat, bahkan di Windows. Lihat https://github.com/fuzzykiller/verify-node-modules.

Memverifikasi bahwa tidak ada hal lain yang ada di node_modules tentu akan memakan waktu sedikit lebih lama tetapi mungkin masih kurang dari satu detik.

Atas dasar ini, versi tambahan npm ci dapat dengan mudah dibuat. Pohon sudah dihitung dan disimpan ke package-lock.json .

Juga, pada dasarnya satu-satunya alasan npm ci ada adalah untuk menginstal apa yang ada di package-lock.json . Tanpa menyelinap dalam peningkatan yang mengejutkan, seperti yang dilakukan npm install .

hanya 2 sen saya, saya secara pribadi mengganti infra kami ke npm ci karena saya juga muak dengan penyebaran tag lama npm i tidak akan mematuhi file kunci ... jadi jika itu serius masalah besar untuk menambahkan flag pada level npm ci (yang saya dapatkan.. clean install melakukan apa yang diperintahkan) maka npm i REALLLLLYLYY membutuhkan flag ini. tapi saya ingat meneliti ini dan ada juga utas masalah di npm i yang berusia lebih dari 2 tahun (dan masih terbuka) di mana tim npm menyarankan orang menggunakan npm ci lol ... ini agak mengapa orang menyerah pada npm di masa lalu dan hanya pergi ke benang.

sekali lagi hanya perspektif devs lainnya

Saya memberikan suara saya untuk menambahkan kemungkinan untuk menyimpan modul :heavy_plus_sign: .

+1 di sini - seperti yang dikatakan @phyzical dan @fuzzykiller , tidak ada "titik manis" antara npm install dan npm ci yang akan MENJAGA node_modules, tetapi tetap menghormati package-lock.json dan berjalan lebih cepat.
Jalankan saja secepat mungkin - cari dependensi dari package-lock yang sudah ada di node_modules, lalu instal semua yang hilang.. tidak ada peningkatan, tidak ada penghapusan.

Secara pribadi saya tidak peduli yang mana ( install atau ci ) yang akan memiliki ini, tetapi semua ini terdengar seperti npm install seharusnya hanya memiliki flag untuk semuanya dan npm ci tidak perlu menjadi perintah terpisah.

Ini agak membuat frustrasi, mengingat npm ci awalnya disebut-sebut sebagai solusi untuk masalah yang sama yang diangkat oleh masalah ini.

Perilaku asli yang diinginkan sejumlah orang untuk npm install adalah melihat package-lock.json alih-alih package.json . Kami ingin tanda pada npm install untuk mengaktifkan perilaku itu. Apa yang kami dapatkan adalah npm ci , karena:

package.json menjelaskan dependensi yang diperlukan dari proyek Anda. Jika file kunci saat ini tidak dapat memenuhinya, file kunci harus menyerah. Tujuan dari lockfile adalah untuk membuat instalasi berulang di mesin yang berbeda, bukan untuk membuat package.json menjadi usang.

Begitu halus. npm install bukan tempat yang tepat untuk opsi itu, npm ci adalah. Kecuali npm ci menambahkan perilaku tambahan (mengosongkan folder node_modules ) yang mencegahnya menjadi solusi yang berguna untuk masalah awal. Dan alasan mengapa tidak ada flag di npm ci sekarang adalah karena:

ci = instalasi bersih

Ini diharapkan. Mengapa Anda tidak menggunakan npm i normal dengan file kunci?

Yang... baik. Saya tidak terlalu peduli di mana bendera ditambahkan. Saya tidak memiliki kepentingan dalam filosofi yang mendasari di balik antarmuka. Tapi bisakah bendera itu ditambahkan di suatu tempat ?

Heck, saya tidak akan mengajukan keberatan bahkan jika orang menginginkan perintah ke-3 yang sepenuhnya terpisah, saya tidak peduli. Satu-satunya hal yang saya pedulikan adalah bahwa 3 tahun setelah percakapan tentang menghormati package-lock.json untuk pemasangan normal ini dimulai, masih belum ada cara untuk mendapatkan perilaku yang awalnya kami minta.

Di tempat kerja saya, kami telah melihat bug dari pembaruan versi minor dan perbaikan bug untuk paket. Kami benar-benar hanya ingin mencari bug tersebut selama peningkatan paket yang disengaja, kami tidak ingin lingkungan dev kami menggunakan versi paket yang berbeda dari lingkungan produksi kami. Konsistensi di sana sangat penting. Apa pun yang ingin disebut atau di mana pun orang ingin meletakkannya, kami menginginkan cara cepat untuk mendapatkan paket dari lockfile yang juga tidak mengharuskan kami untuk duduk melalui node-gyp build untuk modul yang sudah diinstal setiap kali kami menjalankan perintah.

Ini adalah bagaimana saya ingin itu bekerja di dunia yang sempurna:

• npm install - perilaku yang sama seperti hari ini
• npm install --from-lockfile - instal dari file kunci (seperti yang dilakukan ci )
• npm install --clean - perilaku yang sama dengan npm install tetapi hapus konten node_modules
• npm ci - alias untuk npm install --from-lockfile --clean

@jdussouillez Inilah yang seharusnya terjadi. Sangat baik dikatakan! Saya ingin melihat solusi ini diterapkan.

Secara konsisten membuat frustrasi untuk mengalami masalah ini di mana kita harus memutuskan antara kecepatan dan konsistensi untuk pipa CI. Saya telah mengalaminya 3 atau 4 kali untuk alasan yang berbeda dalam 2 bulan terakhir saja.

Fitur ini akan sangat bagus untuk Azure Pipelines dan arsitektur cloud lainnya.

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#tip

Karena npm ci menghapus folder node_modules untuk memastikan bahwa rangkaian modul yang konsisten dan dapat diulang digunakan, Anda harus menghindari caching node_modules saat memanggil npm ci.

Penutup: Seperti yang disebutkan @claudiahdz , kami mengirimkan perbaikan untuk perilaku ini di mana npm ci tidak menghapus folder node_nodules itu sendiri lagi tetapi hanya isinya (ref. https://github.com/npm /libcipm/blob/latest/CHANGELOG.md#407-2019-10-09). Ini dikirim dalam [email protected] kembali pada 21 Juli (ref. https://github.com/npm/cli/blob/v6/CHANGELOG.md#6147-2020-07-21) & kami telah mempertahankan pengalaman yang sama di npm@7 .

Jika Anda memiliki masalah terpisah dengan npm ci atau perintah lainnya, silakan gunakan salah satu template masalah kami untuk mengajukan bug: https://github.com/npm/cli/issues/new/choose

Catatan samping...

@jdussouillez menghargai umpan baliknya; Dalam hal menginstal langsung dari lockfile - Anda dapat melakukannya hari ini dengan flag --package-lock-only (mis. npm install --package-lock-only ). Dalam hal menambahkan flag --clean ke install , saya tidak merasa ini menambah banyak nilai tetapi saya bisa saja salah. Jika Anda merasa yakin tentang hal itu, kami ingin Anda mengirimkan RFC ke https://github.com/npm/rfcs

Komentar yang dibuat oleh @claudiahdz hampir setahun yang lalu tampaknya terkait dengan memastikan perilaku npm ci adalah menghapus konten node_modules , bukan folder itu sendiri. Yang berguna saat memasangnya ke dalam wadah buruh pelabuhan (misalnya), tetapi tetap tidak mengubah hasil akhirnya - npm ci akan mengunduh semua dependensi dari awal.

Menggunakan npm install --package-lock-only tampaknya melakukan kebalikan dari masalah aslinya (Jika saya mengerti dengan benar) - itu hanya akan memperbarui file package-lock.json , dan tidak akan mengunduh dependensi apa pun.

Apa yang saya pahami dari masalah aslinya, adalah perlunya memiliki opsi yang mendapatkan status folder node_modules , dan file package-lock.json , dan hanya mengunduh paket yang diperlukan untuk mendapatkan node_modules versi untuk mencocokkan package-lock.json . Jadi itu akan jauh lebih cepat daripada mengunduh semuanya setiap saat, dengan hasil bersih yang sama di akhir.

Bukankah itu yang selalu dilakukan npm install ?

Bukankah itu yang selalu dilakukan npm install ?

AFAIK -
npm install akan menyelesaikan semua dependensi sesuai dengan file package.json (mengabaikan package-lock.json ), bandingkan dengan apa yang saat ini ada di folder node_modules , dan unduh dependensi yang perlu diunduh agar sesuai dengan persyaratan. Itu juga akan memperbarui package-lock.json sesuai.

Itu pasti tidak mengabaikan lockfile - itu hanya memperhitungkan pohon yang ada, yang npm ci tidak.

Anda benar, saya minta maaf.
Saya salah ingat, (mungkin itu perilaku di masa lalu?). Baru saja melakukan beberapa pengujian dengan pohon dep sederhana, dan ketika file package-lock.json ada, npm i menginstal persis versi yang ditentukan, dan tidak mengubah apa pun. Ini hanya perilaku yang saya cari, jadi saya senang dengan itu. 👍
Saya minta maaf karena memposting tentang masalah tertutup.

Permintaan awal saya memang seperti yang dijelaskan ATGardner:

Apa yang saya pahami dari masalah aslinya, adalah kebutuhan untuk memiliki opsi yang mendapatkan status folder node_modules , dan file package-lock.json , dan hanya mengunduh paket yang diperlukan untuk mendapatkan node_modules versi untuk mencocokkan package-lock.json . Jadi itu akan jauh lebih cepat daripada mengunduh semuanya setiap saat, dengan hasil bersih yang sama di akhir.

Pengalaman saya dengan npm install adalah kadang-kadang memperbarui file package-lock.json . Saya menguji ini lagi pagi ini dengan repositori yang sudah lama tidak saya perbarui dan menjalankan git pull dan npm i . Itu tidak benar-benar memperbarui versi apa pun kali ini, hanya menambahkan beberapa dependensi dan paket tambahan.

Sayangnya ini adalah repositori pribadi tetapi mungkin orang lain sebagai repositori publik yang dapat direproduksi? Di mana ada beberapa komit dan beralih di antara mereka menyebabkan npm install memperbarui package-lock.json ?

Saya menyadari mungkin ada beberapa kesalahan pengguna yang terlibat ketika tidak melakukan package-lock.json saat memperbarui package.json tetapi rekan saya tahu bahwa mereka harus memperbarui package-lock.json juga. Aku akan melihat ke dalam ini.

Saya tidak bisa mendapatkan contoh sederhana untuk meminta npm i mengubah file package-lock.json . Tapi saya akan mencobanya lagi.

Jika npm i selalu berakhir dengan mengunduh versi yang sama persis seperti yang ditentukan dalam package-lock.json , sambil menyimpan sebanyak mungkin dari node_modules , mengapa saya harus menjalankan npm ci ? apa gunanya menghapus semuanya sebelum mengunduh lagi?

Lihat https://docs.npmjs.com/cli/v6/commands/npm-ci#description

Saya mohon maaf sekali lagi karena ini bukan tempat untuk diskusi ini. Apakah ada tempat lain yang lebih disukai?

Aku masih tidak mengerti. Jika keadaan node_modules setelah menjalankan npm i sama persis dengan package-lock.json , dan keadaan node_modules setelah menjalankan npm ci memiliki yang sama persis hasil akhir - di hampir semua skenario, dengan asumsi komputer yang Anda bangun sudah memiliki beberapa/sebagian besar dependensi dalam folder, bukankah npm i akan lebih cepat? Itu tidak akan mengunduh apa yang sudah ada secara lokal, dan cocok dengan versi yang diperlukan.

Mengapa saya lebih suka menghapus dan mengunduh semuanya dari awal?

Tidak, npm ci masih lebih cepat karena tidak memeriksa deptree lagi, beberapa keluaran konsol tidak dilakukan.

Mengapa saya lebih suka menghapus dan mengunduh semuanya dari awal?

Untuk mencegah masalah dan ci adalah untuk lingkungan tertentu seperti penerapan.
Saya pikir dokumen sudah menyebutkan perbedaannya.

Ini bisa jauh lebih cepat daripada instalasi npm biasa dengan melewatkan fitur berorientasi pengguna tertentu. Ini juga lebih ketat daripada instalasi biasa, yang dapat membantu menangkap kesalahan atau inkonsistensi yang disebabkan oleh lingkungan lokal yang diinstal secara bertahap dari sebagian besar pengguna npm.

Lihat juga https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

npm ci masih lebih cepat.

Jadi ketika menggunakan npm i , waktu yang diperlukan untuk membaca node_modules , dan mencari tahu paket mana yang harus diunduh, secara signifikan lebih besar daripada waktu yang diperlukan untuk benar-benar mengunduh semua paket dari npm's server? Saya ingin melihat eksperimen nyata yang mengukurnya.

Dan saya juga tidak mengerti paragraf ini -

npm ci bypasses a package’s package.json to install modules from a package’s lockfile. This ensures reproducible builds—you are getting exactly what you expect on every install.

Bukankah kita baru saja menyimpulkan di sini bahwa menjalankan npm i menggunakan versi yang tepat dalam file package-lock.json , dan status node_modules setelah dijalankan identik dengan statusnya menjadi setelah menjalankan npm ci ? Jadi build akan sama dapat direproduksi.

MEMPERBARUI:

Saya telah membuat tes berikut -
Saya membuat proyek create-react-app baru. Setelah inisialisasi selesai, ia memiliki package.json dengan 7 dependensi langsung, dan package-lock.json yang berisi paket 1982.
Pada keadaan ini ( node_modules berisi semua dependensi) - menjalankan npm i membutuhkan

real    0m2.548s
user    0m2.659s
sys     0m0.182s

Ketika saya menghapus satu folder paket ( node_modules/babel-eslint ), dan kemudian menjalankan npm i lagi, butuh

real    0m3.295s
user    0m3.543s
sys     0m0.434s

untuk mengunduh ulang ketergantungan yang hilang

Ketika saya menghapus seluruh folder node_moduels , dan menjalankan npm i lagi, dibutuhkan

real    0m16.701s
user    0m19.251s
sys     0m10.379s

Ketika saya menjalankan npm ci , dibutuhkan

real    0m20.997s
user    0m23.844s
sys     0m14.857s

Ini tidak berbeda jauh ketika saya mencoba menghapus satu paket, atau bahkan menghapus seluruh folder node_modules secara manual sebelum panggilan. Itu tidak mengejutkan, karena npm ci dimulai dengan menghapus konten node_modules .

Setelah setiap menjalankan, saya menjalankan diff -q -r node_modules_orig/ node_modules/ untuk memastikan hasilnya identik dengan dependensi asli. Itu selalu.

Jadi untuk menyimpulkan - tampaknya menggunakan npm ci membutuhkan ~21 detik di mesin saya, terlepas dari status node_modules . Menggunakan npm i pada proyek yang baru saja dikloning (tidak node_modules ) membutuhkan waktu ~18 detik, dan menjalankannya pada proyek yang tidak memiliki dependensi yang berubah ( node_modules cocok dengan dependensi yang diperlukan ) membutuhkan waktu ~3 detik.

Jadi kapan menggunakan npm ci lebih disukai? Tampaknya tidak lebih cepat (walaupun tentu saja, ini hanya satu tes), dan hasil akhirnya identik dengan npm i , jadi build selanjutnya akan sama andalnya.

npm ci lebih disukai ketika Anda membutuhkan _ persis_ apa yang ada di package-lock.json dan tidak ada apa-apa selain. npm i tidak menjamin bahwa itu akan menginstal persis apa yang ada di package-lock.json . Ini adalah dengan desain. Sementara package-lock.json adalah input ke npm i , itu juga merupakan output.

Saya percaya hanya ada beberapa kasus yang tersisa di mana npm i akan menginstal sesuatu yang berbeda (dan dengan demikian memodifikasi package-lock.json ), seperti mungkin versi paket yang dihapus dengan lembut.

Kembali ketika npm ci pertama kali diperkenalkan, npm i mengabaikan package-lock.json secara langsung atau setidaknya lebih proaktif dalam menginstal versi yang berbeda.

Either way, itu tidak terlalu penting. npm ci hanya OK jika folder node_modules belum ada. Kalau tidak, itu sangat lambat, terutama pada Windows. Jadi npm i hanya membutuhkan sebuah flag yang _menjamin_ itu tidak akan mengubah package-lock.json dan menginstal persis apa yang ada di dalam package-lock.json .

Saya tidak melihat ada gunanya membahas lebih lanjut mengapa dan bagaimana. Entah kita akan mendapatkannya atau tidak. Seperti, npm ci menyebalkan.

/memperbarui:
Inilah repo tempat menjalankan npm i akan mengubah package-lock.json : https://github.com/fuzzykiller/npm-install-demo

Meskipun perubahannya hanya bersifat teknis, itu tetap tidak dapat diterima.

Hanya dengan cepat mengulangi:

• npm ci selalu menghapus konten node_modules berdasarkan desain, yang tidak diinginkan untuk build non-produksi karena lambat. Namun, ia menggunakan versi persis paket yang ditemukan di package-lock.json , yang diinginkan untuk berbagai situasi.

• npm install baru saja memperbarui konten node_modules , yang sangat berkinerja, tetapi dengan desain itu mengabaikan konten package-lock.json jika package.json nomor versi berbeda, yaitu tidak diinginkan untuk beberapa situasi.

• npm install --package-lock-only dijelaskan dalam dokumen :

  Argumen --package-lock-only hanya akan memperbarui package-lock.json, alih-alih memeriksa node_modules dan mengunduh dependensi.

  Ini tampaknya tidak berguna untuk skenario yang dijelaskan di atas.

Apa yang diminta orang selama 3 tahun terakhir:

1. Perintah (di mana saja) yang akan mengabaikan package.json dan _only_ menghormati package-lock.json sebagai sumber definitif dari paket apa yang akan diinstal.

2. Itu tidak akan menghapus seluruh isi node_modules dan mengunduh ulang semuanya dari awal.

Sejauh yang saya lihat dari dokumen dan pengujian lokal, npm install memenuhi poin 2, tetapi tidak 1. npm ci memenuhi poin 1, tetapi tidak 2. npm install --package-lock-only tidak memenuhi apa pun dari persyaratan tersebut.

Saya tidak sepenuhnya yakin mengapa masalah ini telah ditutup, masih belum ada cara untuk mendapatkan perilaku yang diinginkan.

Sunting: Untuk memperluas contoh @fuzzykiller , bukan hanya package-lock.json diperbarui. Itu akan menjengkelkan, tetapi itu tidak akan merusak bangunan saya. Tetapi jika package.json memiliki dependensi fuzzy yang terdaftar di mana saja, dan versi perbaikan bug dari dependensi tersebut dirilis, mereka akan berubah ketika saya menjalankan npm install pada mesin baru. Tiba-tiba saya menginstal perbedaan antara dua mesin. Kami telah mengalami bug di perusahaan saya dari perilaku ini, bukan hanya package-lock.json perlu diperiksa ke Git lagi.

Sangat diinginkan dalam situasi itu untuk memiliki perintah yang berperilaku seperti npm ci -- yang membuat instalasi yang dapat direproduksi berdasarkan _only_ pada konten package-lock.json . Namun, menghapus konten folder node_modules memperlambat build terlalu banyak untuk beberapa lingkungan dan situasi, meskipun itu perilaku yang sesuai untuk build produksi akhir.

Mungkin ada bendera di mana saja untuk mengatasi masalah ini. Bisa jadi npm install --from-lockfile . Bisa jadi npm ci --preserve-existing . Tapi sekarang sepertinya kita berada dalam lingkaran di mana siapa pun yang meminta bendera untuk ditambahkan ke npm install akan diarahkan ke npm ci sebagai solusinya, dan siapa pun yang meminta bendera di npm ci diarahkan ke npm install sebagai solusinya. Masalah ini ditutup dengan menunjuk npm install --package-lock-only , tetapi bendera itu hampir kebalikan dari apa yang diminta orang. Itu tidak menghormati package-lock.json sebagai sumber otoritatif, dan juga tidak memperbarui atau menginstal dependensi apa pun di folder node_modules :)

Masalah ini harus dibuka kembali.