Artikel untuk membincangkan lima peringkat pembangunan pengurusan pakej Node-tutorial js-php.cn

Sejak kelahiran Node pada tahun 2009, ekosistem Node telah berkembang dan berkembang, pengurus pakej Node yang diperoleh daripada ekosistem Node telah berkembang maju, termasuk npm, kpm, pnpm, yarn, cnpm, dsb. Sebenarnya, pembangunan pengurus pakej Node terbahagi terutamanya kepada 5 peringkat Mari kita lihat ciri utama dan produk perwakilan setiap peringkat~

<.>

Fasa Satu: Tebas dan Bakar

Setepatnya, Node tidak wujud tanpa pengurus pakej pada tahun 2009, apabila Node.js keluar prototaip npm juga dikeluarkan. [Cadangan tutorial berkaitan:

tutorial video nodejs, Pengajaran pengaturcaraan]

Nama penuh npm ialah Pengurus Pakej Node.js daripada

Sejarah ringkas Node. js Anda boleh melihatnya di dalam

2009 
Node.js is born 
The first form of npm is created

Salin selepas log masuk

Mari kita bincangkan tentang keadaan sebelum pengurus pakej Node muncul Pada masa itu, lebih banyak perkara telah dilakukan

Cari tapak web rasmi setiap perisian dalam talian, seperti jQuery; dan letakkannya dalam projek yang dipanggil direktori libs;
Jika anda ingin menjadikannya lebih mudah, tampal pautan CDN terus ke dalam HTML
Pengurusan modular pada masa itu? Pengurusan nombor versi? Bergantung pada peningkatan? Tiada satu pun daripada mereka wujud!
Pada tahun 2009, Node.js telah dilahirkan, dan prototaip npm juga telah dikeluarkan pada tahun 2011; dibina di sekitar Kawalan versi Semantik direka bentuk dengan idea semver Secara lalai, pembangun pakej Node akan meningkatkan nombor versi mengikut spesifikasi semver apabila menaik taraf nombor versi tersuai bagi pakej bergantung.

Kata Ganti Nama:

Penyeragaman pengurusan pakej nod, kebergantungan storan bersarang direktori node_modules

Produk perwakilan:

npm v1, versi v2

Ciri utama:

(1) Pemasangan bersarang bagi pakej bergantung, kebergantungan versi yang sama akan dipasang secara berlebihan

(2) Ketidakpastian pemasangan pakej bergantung: Yang terkini versi pakej kebergantungan dipasang secara lalai (versi tetap boleh ditetapkan)

(3) Pemasangan bersiri kebergantungan lambat;

Pemasangan bersarang

, jika A bergantung pada B dan B bergantung pada C, direktori node_modules adalah seperti berikut

Masalah:

Ketergantungan bersarang Ini selalunya akan menyebabkan neraka bersarang Pada masa yang sama, akan terdapat sejumlah besar pemasangan berlebihan bagi pakej bergantung yang sama, menyebabkan node_modules menjadi terlalu besar, memerlukan pengaturcara untuk kerap rm -rf node_modules. banyak program pada sistem Windows tidak boleh mengendalikan lebih daripada 260 aksara nama laluan fail, pengguna awal npm Windows telah melihat tetingkap timbul ini

Penjelasan 2. : Versi kebergantungan terkini dipasang secara lalai untuk setiap pemasangan npm , menyebabkan pemasangan kebergantungan

node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js

Salin selepas log masuk

Ketidakpastian

Masalah:

pembantu menyeragamkan versi komposisi nombor: X.Y.Z-[state], naik taraf nombor versi Spesifikasi adalah seperti berikut

X ialah nombor versi utama: Apabila perubahan API tidak serasi dengan versi lama, naik taraf major nombor versi Y ialah nombor versi kecil: Ditambah API Baharu, tetapi serasi ke belakang, tingkatkan nombor versi kecil Z ialah nombor versi tampung: Apabila pembaikan kecacatan serasi ke belakang dibuat,

keadaan boleh menjadi: alpha (beta dalaman) , beta (beta awam), gamma (versi beta agak matang), rc (pra-keluaran)

Sebab mengapa versi tidak pasti

Penyelesaian 1 : Gunakan perintah npm config set save-exact true untuk mematikan penggunaan di hadapan kelakuan lalai nombor versi ^
Ringkasan: Tidak dapat menyelesaikan masalah kebergantungan perpustakaan kebergantungan sendiri memasang versi terkini secara lalai

Penyelesaian 2: npm menyediakan arahan shrinkwrap , fail akan dihasilkan untuk merekodkan versi yang tepat untuk semua perpustakaan dan semua perpustakaan bergantung bersarang

Ringkasan: Fail kunci tidak akan dijana secara lalai dan memerlukan pengguna untuk melaksanakan arahan secara manual; Bergantung pada pengguna mengetahui arahan ini, ia agak menyusahkan

npm-shrinkwrap.jsonPada tahun 2015, untuk menyelesaikan masalah pembenaman dalam npm1 dan npm2 Untuk menyelesaikan masalah pemasangan pakej dan versi yang tidak konsisten, program npm telah sepenuhnya ditulis semula
Kata Ganti Nama:
Pemasangan dengan kurang kebergantungan berlebihan, direktori node_modules diratakan untuk menyimpan kebergantungan

Produk perwakilan:

versi npm v3 Penerangan ringkas tentang prinsip: Apabila npm memasang, bina pepohon kebergantungan dahulu dan kemudian pasang semua kebergantungan dalam direktori akar node_modules Apabila sub-bergantungan menemui versi kebergantungan yang berbeza dengan nama yang sama, ia akan dipasang dalam Under your own node_modules

Ciri utama:

(1) Kurangkan pemasangan berlebihan: bergantung pada pemasangan rata, yang mengurangkan pemasangan pakej berlebihan di bawah tertentu keadaan

Masalah sedia ada:

(1) "Pergantungan hantu", "Pergantungan hantu" Masalah

(2) "Orang asing kembar", " Pakej kebergantungan" "Klon" masalah

(3) Direktori tidak tetap: susunan pemasangan kebergantungan menentukan struktur direktori node_module

Penjelasan 1: Susunan pemasangan kebergantungan menentukan struktur direktori node_modules

Senario berikut: App1 bergantung pada packageA dan packageC dan packageG dan packageH, dan packageA dan packageC kedua-duanya bergantung pada packageB v1.0, dan packageG dan packageH kedua-duanya bergantung pada versi v2.0 packageB

Jika packageA atau packageC dipasang dahulu, direktori node_modules adalah seperti berikut

Jika packageG atau packageH ialah dipasang dahulu, direktori node_modules adalah seperti berikut

Sebagai tindak balas kepada situasi di atas, npm menyediakan arahan `npm dedupe` untuk menyusun & memudahkan struktur direktori node_modules struktur direktori node_modules adalah konsisten dan tidak dipengaruhi oleh susunan pemasangan pakej bergantung

Penjelasan 2: Ia mungkin tidak semestinya mengurangkan pemasangan pakej berlebihan

Melalui Contoh 1, dapat dilihat bahawa walaupun pakej kebergantungan dipasang secara rata, masih terdapat pakej kebergantungan versi yang sama, dan terdapat Pakej Yu yang berlebihan

Penjelasan 3: Masalah "Twin Strangers"

Rujuk Contoh 1, versi pakej bergantung yang sama telah dipasang dua kali dan diletakkan di dua tempat , fenomena ini dipanggil "orang asing kembar"

Penjelasan 4: "Kebergantungan hantu " masalah

pakej kebergantungan dalam direktori peringkat pertama node_modules, pembangun boleh Jika digunakan secara terus, tetapi pakej kebergantungan tidak ditakrifkan dalam package.json, pakej kebergantungan tersebut dipanggil "kebergantungan hantu". Jika "ghost dependency" digunakan dalam projek hadapan, masalah mungkin berlaku kemudian.

Oleh kerana "kebergantungan hantu" ini mungkin dialih keluar bersama-sama dengan peningkatan kebergantungan lain, ia tidak akan wujud lagi dalam node_modules Apabila melaksanakan pemasangan npm, "kebergantungan hantu" tidak akan dipasang secara subjektif Hasilnya, projek tidak dapat mencari pakej bergantung dan kemudian melaporkan ralat.

Fasa 4: Keselamatan dan mempercepatkan

Pada tahun 2016, versi keluaran benang dan pnpm muncul satu demi satu, yang pada tahap tertentu menyelesaikan ketidakpastian versi pemasangan sebelumnya dan kelajuan pemasangan. Kelambatan dan masalah lain, keupayaan pertama kali dilancarkan oleh benang lebih menarik perhatian daripada npm, memastikan konsistensi & keselamatan, dan meningkatkan kelajuan pemasangan

Kata ganti nama: Pemasangan bergantung adalah agak selamat, Percepatkan

Produk wakil: versi keluaran benang, versi keluaran pnpm, versi npm v5 (npm v4 tidak banyak berubah, v5 adalah langkah besar ke hadapan)

Ciri utama:

(1) Keselamatan: Fail kunci versi dijana secara lalai, memastikan versi bergantung adalah sama setiap kali anda memasangnya

(2) Mempercepatkan: Menambah cache luar talian Pemasangan, pemasangan selari, cuba semula automatik selepas pengecualian pemasangan

(3) ruang kerja: benang disokong daripada versi v1, dan boleh mengurus pakej pergantungan berbilang projek dengan cekap ; hanya npm v7 menyokong ruang kerja

Masalah sedia ada:

(1) Kebergantungan hantu

(2) Pemasangan berulang bagi projek tunggal dan silang pakej kebergantungan projek

(3) Direktori tidak tetap: susunan pemasangan kebergantungan menentukan struktur direktori node_module

Penjelasan 1: Mengenai keselamatan

Versi benang v0.x adalah yang pertama, versi npm v5.x lebih ketat Selepas itu, apabila memuat turun kebergantungan, fail kunci kebergantungan dijana secara lalai, yang mengunci versi dengan tepat pada nilai

yarn's . fail kunci: ia hanya merekodkan versi pergantungan yang dipasang dan perlu digabungkan dengan package.json Tentukan struktur direktori node_modules

fail .lock npm: merekodkan versi pergantungan yang dipasang dan struktur direktori node_modules

Ringkasan: Mengelakkan keperluan untuk memasang kebergantungan pada terminal yang berbeza Masalah ketidakkonsistenan versi, tetapi masalah "kebergantungan hantu" masih wujud

Penjelasan 2: Mengenai peningkatan kelajuan - cache luar talian

versi npm v2 menyokong caching, tetapi memerlukan sambungan Internet untuk pengesanan , untuk menggunakan kebergantungan cache

versi v0.x yarn ialah yang pertama menyokong cache luar talian yang dimuat turun daripada rangkaian akan dicache secara global. Pemasangan seterusnya akan memberi keutamaan untuk mencari secara setempat dan menyalin terus jika ditemui

Versi npm v5 menulis semula sistem cache dan juga menyokong pemasangan luar talian dengan sangat baik

Penjelasan 3: Mengenai peningkatan kelajuan - pemasangan selari

benang adalah yang pertama menyokong kebergantungan Pakej dipasang secara selari Sebelum ini, npm memasang kebergantungan secara bersiri pemasangan selari

Penjelasan 4: Selepas memasang kebergantungan, direktori node_modules disusun secara automatik

Masa mula ：versi yarn v1.x, versi npm v4.x

Jika fail `.lock` dipadamkan daripada projek, direktori node_modules akan disusun secara automatik apabila kebergantungan dimulakan untuk dipasang untuk versi sebelum npm v4 >Oleh kerana node_modules ialah kebergantungan pengurusan rata, kebergantungan dalam boleh dipasang dalam direktori peringkat pertama; apabila versi kebergantungan yang berbeza dipasang dalam projek dan konflik versi kebergantungan ditemui, kebergantungan dalam akan dialihkan secara automatik dari direktori peringkat pertama ke direktori induk direktori `npm dedupe`【Disahkan】

Fasa 5: Lebih selamat, kelajuan tinggi, penggunaan rendah

Menghadapi kematangan pnpm, Pembangun menikmati faedah penggunaan storan yang lebih selamat, lebih cepat, dan lebih rendah yang dibawa oleh pnpm, menyelesaikan masalah "hantu kebergantungan" dan menyelesaikan masalah kebergantungan berulang

Kata Ganti Nama:
Keselamatan (Bergantung pada pemasangan WYSIWYG ), kelajuan tinggi (tiada pemasangan berulang), penggunaan storan rendah (pautan keras + pautan lembut)
Produk wakil:
pnpm
Ciri-ciri utama:

(1) Sangat pantas
: Pusat storan mengurus kebergantungan secara berpusat dan dikaitkan secara langsung dengan
projek. Berbanding dengan kaedah kerja sebelumnya, sejumlah besar operasi IO daripada salinan global node_modules ke dalam projek dikurangkan `node_modules/.pnpm` (2) Penggunaan cakera sangat tinggi
:
Kongsi kebergantungan versi yang sama merentas projek: pautan keras, pautan lembut

Maksimumkan penggunaan semula versi berbeza bagi kebergantungan yang sama: hanya tambahkan fail Diff untuk menyimpan versi berbeza

(3 ) Keselamatan tinggi: Struktur direktori node_modules ialah senarai kebergantungan package.json, yang menyelesaikan masalah "kebergantungan hantu"

Prestasinya adalah seperti berikut :

Untuk lebih banyak pengetahuan berkaitan nod, sila lawati: tutorial nodejs
!

Atas ialah kandungan terperinci Artikel untuk membincangkan lima peringkat pembangunan pengurusan pakej Node. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!