Analisis mendalam tentang mekanisme manajemen paket npm

Penulis：Eve Cole Waktu Pembaruan：2022-09-21 09:19:40

Kursus masuk ke penguasaan front-end (vue): Memasuki pembelajaran

Saat ini, siswa pengembangan front-end tidak dapat melakukannya tanpa npm , sebuah alat manajemen paket. Mekanisme manajemen versi paket yang sangat baik membawa seluruh komunitas NodeJS yang makmur untuk memahami mekanisme internalnya. Ini membantu memperdalam pemahaman kita tentang pengembangan modul dan berbagai konfigurasi teknik front-end untuk mempercepat pemecahan masalah kita (saya yakin banyak siswa mengalami masalah dengan berbagai masalah ketergantungan).

Artikel ini melakukan analisis mendetail tentang mekanisme manajemen paket npm dari tiga perspektif: package.json , manajemen versi, instalasi ketergantungan, dan contoh spesifik.

1. Analisis package.json

Di Node.js , modul adalah perpustakaan atau kerangka kerja dan juga proyek Node.js Proyek Node.js mengikuti arsitektur modular. Ketika kita membuat proyek Node.js , berarti membuat modul. Modul ini harus memiliki file deskripsi yaitu package.json . Ini adalah file konfigurasi kami yang paling umum, tetapi apakah Anda benar-benar memahami konfigurasi di dalamnya secara detail? Mengonfigurasi file package.json yang masuk akal secara langsung menentukan kualitas proyek kita, jadi pertama-tama kita akan menganalisis konfigurasi detail package.json .

1.1 Atribut yang diperlukan

Ada banyak atribut di package.json , dan hanya dua yang harus diisi: name dan version . Kedua atribut ini membentuk pengenal unik modul npm .

aturan penamaan paket npm

name adalah nama modul. Saat memberi nama, Anda harus mengikuti beberapa spesifikasi dan rekomendasi resmi:

nama paket akan menjadi parameter dalam url modul, baris perintah, atau nama folder url pun ada dalam nama paket. Tidak ada yang dapat digunakan. Anda dapat menggunakan paket validate-npm-package-name untuk memeriksa apakah nama paket tersebut sah.
Nama paket semantik dapat membantu pengembang menemukan paket yang diperlukan dengan lebih cepat dan menghindari mendapatkan paket yang salah secara tidak sengaja.
Jika ada beberapa simbol pada nama paket, simbol tersebut tidak boleh diulangi dengan nama paket yang ada setelah dihapus.

Misalnya: karena react-native sudah ada, react.native dan reactnative tidak dapat dibuat lagi.

Jika nama paket Anda terlalu mirip dengan nama paket yang ada dan Anda tidak dapat mempublikasikan paket tersebut, disarankan untuk mempublikasikan paket tersebut ke cakupan Anda.

Misalnya: nama penggunanya adalah conard , maka cakupannya adalah @conard , dan paket yang diterbitkan dapat berupa @conard/react .

Periksa apakah paket sudah terisi.

name adalah pengidentifikasi unik dari sebuah paket dan tidak boleh diulangi dengan nama paket lainnya. Kita dapat menjalankan npm view packageName untuk melihat apakah paket tersebut sudah terisi, dan kita dapat melihat beberapa informasi dasar tentangnya:

Jika nama paket belum pernah digunakan, kesalahan 404 akan muncul:

Selain itu, Anda juga dapat mengunjungi https://www.npmjs.com/ untuk informasi paket lebih detail.

1.2

Deskripsi dasar

informasi deskripsi

{
  "description": "Bahasa desain UI kelas enterprise dan implementasi komponen React",
  "kata kunci": [
    "semut",
    "komponen",
    "komponen",
    "desain",
    "kerangka",
    "depan",
    "bereaksi",
    "komponen reaksi",
    "ui"
  ]
}

description digunakan untuk menambahkan informasi deskripsi modul agar memudahkan orang lain memahami modul Anda.

keywords digunakan untuk menambahkan kata kunci ke modul Anda.

Tentunya mereka juga memegang peranan yang sangat penting yaitu untuk memudahkan pengambilan modul. Saat Anda menggunakan npm search untuk mengambil modul, modul tersebut akan cocok dengan description dan keywords . Menulis description dan keywords yang baik akan membantu modul Anda mendapatkan eksposur yang lebih banyak dan akurat:

Ada dua bidang bagi

pengembang

untuk mendeskripsikan pengembang: author dan contributors . author mengacu pada penulis utama paket, dan satu author berhubungan dengan satu orang.

Kontributor mengacu pada informasi kontributor. Satu

kontributor

contributors contributors beberapa kontributor. Nilainya berupa array.

 
    "nama": "ConardLi", 
    "email" : "[email protected]", 
    "url" : "https://github.com/ConardLi"
}

alamat

{
  "beranda": "http://ant.design/",
  "bug": {
    "url": "https://github.com/ant-design/ant-design/issues"
  },
  "repositori": {
    "ketik": "git",
    "url": "https://github.com/ant-design/ant-design"
  },
}

homepage digunakan untuk menentukan beranda modul ini.

repository digunakan untuk menentukan repositori kode modul.

bugs menentukan alamat atau email dimana orang yang memiliki pertanyaan tentang modul Anda dapat pergi ke sini untuk mengajukan pertanyaan.

1.3 Konfigurasi ketergantungan

Proyek kami mungkin bergantung pada satu atau lebih paket ketergantungan eksternal. Menurut perbedaan penggunaan paket ketergantungan, kami mengonfigurasinya berdasarkan atribut berikut: dependencies、devDependencies、peerDependencies、bundledDependencies、optionalDependencies .

Aturan Konfigurasi

Sebelum memperkenalkan beberapa konfigurasi dependensi, pertama-tama mari kita lihat aturan konfigurasi dependensi. Konfigurasi paket dependensi yang Anda lihat mungkin sebagai berikut:

"dependensi": {
      "antd": "ant-design/ant-design#4.0.0-alpha.8",
      "aksios": "^1.2.0",
      "test-js": "file:../test",
      "test2-js": "http://cdn.com/test2-js.tar.gz",
      "core-js": "^1.1.5",
 }

Konfigurasi ketergantungan mengikuti aturan konfigurasi berikut:

依赖包名称:VERSION
- VERSION adalah konfigurasi nomor versi yang mengikuti spesifikasi SemVer . Ketika npm install ia akan menuju ke server npm untuk mengunduh paket yang memenuhi rentang versi yang ditentukan.
依赖包名称:DWONLOAD_URL
- DWONLOAD_URL adalah alamat paket terkompresi tarball yang dapat diunduh. Ketika modul diinstal, .tar ini akan diunduh dan diinstal secara lokal.
依赖包名称:LOCAL_PATH
- LOCAL_PATH adalah jalur paket ketergantungan lokal, seperti file:../pacakges/pkgName . Cocok bagi Anda untuk menguji paket npm secara lokal, cara ini sebaiknya tidak diterapkan secara online.
依赖包名称:GITHUB_URL
- GITHUB_URL tag metode penulisan username/modulename github , misalnya: ant-design/ant-design commit id
依赖包名称:GIT_URL
- GIT_URL adalah git url dari basis kode klon biasa, yang mengikuti bentuk berikut:

<protocol>://[<user>[:<password>]@]<hostname>[:<port>] [: ][/]<path>[#<commit-ish> |. #semver:<semver>]

protocal dapat dalam bentuk berikut:

git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish

-ish

dependencies menentukan modul yang menjadi sandaran proyek. Baik modul ketergantungan lingkungan pengembangan maupun lingkungan produksi dapat dikonfigurasi di sini, seperti

" ketergantungan": {
      "lodash": "^4.17.13",
      "momen": "^2.24.0",
 }

Ada beberapa paket di

devDependencies

yang hanya dapat Anda gunakan di lingkungan pengembangan, seperti eslint untuk memeriksa spesifikasi kode dan jest untuk pengujian. Saat pengguna menggunakan paket Anda, paket tersebut dapat berjalan secara normal bahkan tanpa menginstal dependensi ini akan memerlukan lebih banyak waktu dan sumber daya, sehingga Anda dapat menambahkan dependensi ini ke devDependencies . Dependensi ini akan tetap diinstal dan dikelola ketika Anda melakukan npm install secara lokal, namun tidak akan diinstal ke dalam lingkungan produksi:

"devDependencies" : {
      "lelucon": "^24.3.1",
      "eslint": "^6.1.0",
 }

peerDependencies

peerDependencies digunakan untuk menentukan versi dimana modul yang Anda kembangkan bergantung dan kompatibilitas versi paket dependen yang diinstal oleh pengguna.

Pernyataan di atas mungkin agak terlalu abstrak. Mari kita ambil ant-design sebagai contoh. package.json dari ant-design memiliki konfigurasi berikut:

"peerDependencies": {
    "reaksi": ">=16.0.0",
    "reaksi-dom": ">=16.0.0"
  }

Saat Anda mengembangkan sistem dan menggunakan ant-design , Anda pasti harus mengandalkan React . Pada saat yang sama, ant-design juga perlu mengandalkan React . Versi React yang diperlukan untuk mempertahankan operasi yang stabil adalah 16.0.0 , dan versi React yang Anda andalkan saat mengembangkannya adalah 15.x :

Saat ini, ant-design perlu menggunakan React , dan Impor:

import * as React from 'react';
import * as ReactDOM from 'react-dom';

Apa yang Anda dapatkan saat ini adalah lingkungan host, yang merupakan versi React di lingkungan Anda, yang mungkin menyebabkan beberapa masalah. Dalam npm2 , menentukan peerDependencies di atas berarti memaksa lingkungan host untuk menginstal versi react@>=16.0.0和react-dom@>=16.0.0 .

Di masa depan, npm3 tidak lagi memerlukan paket ketergantungan yang ditentukan oleh peerDependencies untuk diinstal secara paksa. Sebaliknya npm3 akan memeriksa apakah instalasi sudah benar setelah instalasi selesai .

"ketergantungan": {
    "bereaksi": "15.6.0",
    "antd": "^3.22.0"
  }

Misalnya, saya mengandalkan antd versi terbaru dalam proyek, dan kemudian mengandalkan react versi 15.6.0 . Peringatan berikut akan diberikan saat menginstal dependensi:

opsionalDependencies

Dalam beberapa skenario, paket dependen mungkin bukan ketergantungan yang kuat. Fungsi paket dependen ini dapat diabaikan. Ketika paket dependen ini tidak dapat diperoleh, Anda ingin npm install terus berjalan tanpa menyebabkan kegagalan optionalDependencies . Perhatikan bahwa konfigurasi di optionalDependencies akan mengesampingkan dependencies sehingga hanya perlu dikonfigurasi di satu tempat.

Tentu saja, ketika mereferensikan dependensi yang dipasang di optionalDependencies , penanganan pengecualian harus dilakukan, jika tidak, kesalahan akan dilaporkan ketika modul tidak dapat diperoleh.

bundledDependencies

berbeda dari yang di atas. Nilai dari bundledDependencies adalah sebuah array. Beberapa modul dapat ditentukan dalam array. Modul-modul ini akan dipaketkan bersama-sama ketika paket ini dirilis.

"bundledDependencies": ["package1" , "package2"]

1.4 protokol

{
    "lisensi": "MIT"
}

Bidang license digunakan untuk menentukan perjanjian sumber terbuka perangkat lunak. Perjanjian sumber terbuka merinci hak yang dimiliki orang lain setelah mendapatkan kode Anda, operasi apa yang dapat mereka lakukan pada kode Anda, dan operasi apa yang dilarang. Ada banyak varian dari perjanjian yang sama. Perjanjian yang terlalu longgar akan menyebabkan pencipta kehilangan banyak hak atas karya tersebut, sedangkan perjanjian yang terlalu ketat tidak akan nyaman bagi pengguna untuk menggunakan dan menyebarkan karya tersebut , penulis open source harus mempertimbangkan hak mana yang ingin mereka pertahankan dan batasan mana yang ingin mereka longgarkan.

Perjanjian perangkat lunak dapat dibagi menjadi dua kategori: sumber terbuka dan komersial. Untuk perjanjian komersial, juga disebut pernyataan hukum dan perjanjian lisensi, setiap perangkat lunak akan memiliki kumpulan teksnya sendiri, yang ditulis oleh pembuat perangkat lunak atau pengacara khusus. tidak perlu melakukannya sendiri. Menghabiskan waktu dan tenaga untuk menulis perjanjian lisensi yang panjang. Memilih lisensi open source yang beredar luas adalah pilihan yang baik.

Berikut ini adalah beberapa protokol open source utama:

MIT : Selama pengguna menyertakan pemberitahuan hak cipta dan pemberitahuan lisensi dalam salinan proyek mereka, mereka dapat melakukan apa pun yang mereka inginkan dengan kode Anda tanpa tanggung jawab apa pun dari Anda.
Apache : Mirip dengan MIT , tetapi juga mencakup istilah terkait lisensi paten yang diberikan oleh kontributor kepada pengguna.
GPL : Pengguna yang mengubah kode proyek harus mempublikasikan modifikasi yang relevan ketika mendistribusikan ulang kode sumber atau kode biner.

Jika Anda memiliki persyaratan lebih rinci untuk perjanjian sumber terbuka, Anda dapat mengunjungi Choosealicense.com/ untuk penjelasan lebih rinci tentang perjanjian sumber terbuka.

1.5

Pintu masuk program

terkait direktori dan file

{
  "utama": "lib/index.js",
}

Atribut main dapat menentukan file entri utama program. Misalnya, entri modul lib/index.js yang ditentukan oleh antd di atas. Saat kita memasukkan antd dalam kode: import { notification } from 'antd'; yang diperkenalkan adalah lib/index.js .

Entri alat baris perintah

Jika modul Anda adalah alat baris perintah, Anda perlu menentukan entri untuk alat baris perintah, yaitu menentukan korespondensi antara nama perintah Anda dan file lokal yang dapat ditentukan. Jika dipasang secara global, npm akan menggunakan tautan simbolik untuk menautkan file yang dapat dieksekusi ke /usr/local/bin . Jika dipasang secara lokal, ia akan tertaut ke ./node_modules/.bin/ .

{
    "tempat sampah": {
    "conard": "./bin/index.js"
  }
}

Misalnya, konfigurasi di atas: Ketika paket Anda diinstal secara global: npm akan membuat tautan lunak bernama conard di bawah /usr/local/bin , menunjuk ke "./bin/index.js" . Saat ini, jika Anda menjalankan conard pada baris perintah, file js yang tertaut akan dipanggil.

Saya tidak akan membahas terlalu banyak detail di sini, lebih banyak konten akan dijelaskan secara detail di artikel alat baris perintah saya berikutnya.

publikasikan konfigurasi file

{
    "file": [
      "dist",
      "lib",
      "es"
    ]
}

Atribut files digunakan untuk mendeskripsikan daftar file yang Anda kirim ke server npm setelah npm publish . Jika Anda menentukan folder, semua konten dalam folder tersebut akan disertakan. Kita dapat melihat bahwa paket yang diunduh memiliki struktur direktori berikut:

Selain itu, Anda juga dapat mengonfigurasi file .npmignore untuk mengecualikan beberapa file guna mencegah sejumlah besar file sampah dikirim ke npm . Aturannya sama dengan .gitignore yang Anda gunakan. File .gitignore juga dapat bertindak sebagai file .npmignore .

man

Perintah man adalah perintah bantuan di Linux . Melalui perintah man , Anda dapat melihat bantuan perintah, bantuan file konfigurasi, bantuan pemrograman, dan informasi lainnya di Linux .

Jika modul node.js Anda adalah alat baris perintah global, Anda dapat menentukan alamat dokumen yang dicari dengan perintah man melalui atribut man di package.json .

file man harus diakhiri dengan angka atau, jika dikompresi, .gz . Nomor tersebut menunjukkan di bagian man file tersebut akan diinstal. Jika nama file man tidak diawali dengan nama modul, nama modul akan diawali saat instalasi.

Misalnya konfigurasi berikut:

{ 
  "pria" : [ 
    "/Pengguna/isaacs/dev/npm/cli/man/man1/npm-access.1",
    "/Pengguna/isaacs/dev/npm/cli/man/man1/npm-audit.1"
  ]
}

Masukkan man npm-audit pada baris perintah:

Direktori proyek standar

Modul node.js diimplementasikan berdasarkan spesifikasi modular CommonJS Sesuai dengan spesifikasi CommonJS , selain file deskripsi paket package.json , direktori modul juga harus berisi direktori berikut:

bin : di mana file biner yang dapat dieksekusi disimpan. Direktori
lib : Direktori untuk menyimpan kode js
doc : Direktori untuk menyimpan dokumen
test : Direktori untuk menyimpan kode kasus uji unit
...

Di direktori modul, Anda tidak boleh mengikuti struktur di atas secara ketat untuk mengatur atau memberi nama itu. . Anda dapat menentukan directories di package.json Properties untuk menentukan bagaimana struktur direktori Anda sesuai dengan struktur kanonik di atas. Selain itu, atribut directories tidak memiliki aplikasi lain untuk saat ini.

{
  "direktori": {
    "lib": "src/lib/",
    "tempat sampah": "src/tempat sampah/",
    "pria": "src/pria/",
    "doc": "src/doc/",
    "contoh": "src/contoh/"
  }
}

Namun, dokumen resmi menyatakan bahwa meskipun atribut ini saat ini tidak memiliki peran penting, beberapa trik mungkin akan dikembangkan di masa mendatang, misalnya file penurunan harga yang disimpan di doc dan file contoh yang disimpan di example dapat ditampilkan dengan cara yang ramah.

1.6

Skrip

konfigurasi skrip

{
  "skrip": {
    "test": "jest --config .jest.js --no-cache",
    "dist": "antd-tools menjalankan dist",
    "kompilasi": "antd-tools menjalankan kompilasi",
    "build": "npm run kompilasi && npm run dist"
  }
}

scripts digunakan untuk mengonfigurasi singkatan dari beberapa perintah skrip. Setiap skrip dapat digunakan dalam kombinasi satu sama lain. Skrip ini dapat mencakup seluruh siklus hidup proyek. Setelah konfigurasi, skrip tersebut dapat dipanggil menggunakan npm run command . Kalau kata kunci npm bisa langsung dipanggil. Misalnya, konfigurasi di atas menetapkan perintah berikut: npm run test , npm run dist , npm run compile , npm run build .

config

Bidang config digunakan untuk mengonfigurasi variabel lingkungan yang digunakan dalam skrip. Misalnya, konfigurasi berikut dapat diperoleh menggunakan process.env.npm_package_config_port dalam skrip.

{
  "konfigurasi" : { "pelabuhan" : "8080" }
}

1.7 Konfigurasi rilis

preferGlobal

Jika modul node.js Anda terutama digunakan untuk menginstal alat baris perintah global, maka nilai ini disetel ke true , dan pengguna akan mendapat peringatan saat mereka menginstal modul secara lokal. Konfigurasi ini tidak akan menghalangi pengguna untuk menginstal, namun akan meminta pengguna untuk mencegah penggunaan yang salah yang dapat menyebabkan beberapa masalah.

private

Jika atribut private disetel ke true , npm akan menolak untuk mempublikasikannya. Hal ini untuk mencegah modul private dipublikasikan secara tidak sengaja.

terbitkanConfig

"publishConfig": {
    "registrasi": "https://registry.npmjs.org/"
  },

konfigurasi yang lebih detail saat menerbitkan modul, misalnya, Anda dapat mengonfigurasi untuk menerbitkan hanya tag tertentu, mengonfigurasi sumber npm pribadi untuk dipublikasikan.

Untuk

konfigurasi lebih detail, silakan merujuk ke npm-config

os.

Jika Anda mengembangkan modul yang hanya dapat berjalan di bawah sistem darwin , Anda perlu memastikan bahwa pengguna windows tidak akan menginstal modul Anda untuk menghindari kesalahan yang tidak perlu.

Menggunakan atribut os dapat membantu Anda memenuhi persyaratan di atas. Anda dapat menentukan bahwa modul Anda hanya dapat diinstal pada sistem tertentu, atau menentukan daftar hitam sistem yang tidak dapat diinstal:

"os" : [ "darwin", "linux" ]
"os" : [ "!win32" ]

Misalnya, saya menetapkan modul pengujian ke daftar hitam sistem: "os" : [ "!darwin" ] . Ketika saya menginstalnya di sistem ini, kesalahan berikut akan muncul:

Di lingkungan node, Anda dapat menggunakan process.platform untuk menentukan sistem operasi.

CPU

mirip dengan os di atas. Kita dapat menggunakan atribut cpu untuk membatasi lingkungan instalasi pengguna dengan lebih akurat:

"cpu" : [ "x64", "ia32" ]
"cpu" : [ "!arm", "!mips" ]

Di lingkungan node, Anda dapat menggunakan process.arch untuk menentukan arsitektur CPU.

2. Analisis mekanisme manajemen versi paket

Keberhasilan Nodejs tidak terlepas dari sistem manajemen ketergantungan npm yang sangat baik. Sebelum memperkenalkan keseluruhan sistem ketergantungan, Anda harus memahami bagaimana npm mengelola versi paket dependen. Bab ini akan memperkenalkan spesifikasi rilis versi npm包, cara mengelola versi berbagai paket dependen, dan beberapa praktik terbaik terkait versi paket.

2.1 Lihat versi paket npm

Anda dapat menjalankan npm view package version untuk melihat versi terbaru suatu package .

Jalankan npm view conard versions untuk melihat semua versi package yang dipublikasikan di server npm.

Jalankan npm ls untuk melihat informasi versi semua paket di pohon ketergantungan gudang saat ini.

2.2 Spesifikasi SemVer

Versi modul dalam npm包harus mengikuti spesifikasi SemVer - aturan representasi nomor versi terpadu yang dirancang oleh Github . Ini sebenarnya adalah singkatan dari Semantic Version .

Situs web resmi spesifikasi SemVer: https://semver.org/Versi

standar

Nomor versi standar spesifikasi SemVer mengadopsi format XYZ , di mana X, Y dan Z adalah bilangan bulat non-negatif, dan bantalan nol di depan angka adalah dilarang. X adalah nomor versi mayor, Y adalah nomor versi minor, dan Z adalah nomor revisi. Setiap elemen harus bertambah secara numerik.

Nomor versi utama ( major ): Saat Anda membuat modifikasi API yang tidak kompatibel
Nomor versi minor ( minor ): Saat Anda membuat fungsionalitas yang kompatibel ke belakang
Nomor revisi baru ( patch ): Saat Anda membuat masalah kompatibilitas ke belakang Koreksi.

Misalnya: 1.9.1 -> 1.10.0 -> 1.11.0

versi lanjutan.

Jika suatu versi mengalami perubahan besar, tidak stabil, dan mungkin tidak memenuhi persyaratan kompatibilitas yang diharapkan, Anda mungkin ingin merilis versi lanjutan terlebih dahulu.

Nomor versi terdepan dapat ditambahkan di akhir "nomor versi utama. Nomor versi minor. nomor revisi". Pertama-tama tambahkan nomor koneksi dan kemudian serangkaian pengidentifikasi dan informasi kompilasi versi yang dipisahkan berdasarkan titik.

Versi internal ( alpha ):
Versi beta publik ( beta ):
Versi kandidat dari versi resmi rc : Release candiate

versi kandidat React

Mari kita lihat versi historis dari React :

Dapat dilihat bahwa versi ini dirilis secara ketat sesuai dengan spesifikasi SemVer :

16.8.0 -> 16.8.1 -> 16.8.2
versi benar-benar sesuai dengan format主版本号.次版本号.修订号
16.8.0 -> 16.8.1 -> 16.8.2
merilis versi utama Atau ketika perubahan versi besar, alpha , beta , rc dan versi lanjutan lainnya

biasanya

dirilis terlebih dahulu

Setelah memodifikasi fungsi tertentu dari paket npm , biasanya perlu untuk merilis a versi baru. Pendekatan kami yang biasa adalah memodifikasi package.json secara langsung ke versi yang ditentukan. Jika pengoperasiannya salah, mudah menimbulkan kebingungan pada nomor versi. Kita dapat menggunakan perintah yang sesuai dengan spesifikasi Semver untuk menyelesaikan operasi ini:

npm version patch : tingkatkan nomor revisi
npm version minor : tingkatkan nomor versi minor
npm version major : perbarui nomor versi mayor

2.3 Penggunaan alat versi

dalam pengembangan jelas sangat diperlukan untuk pengoperasian beberapa nomor versi. Jika nomor versi ini sesuai dengan spesifikasi SemVer , kita dapat menggunakan paket npm semver untuk versi pengoperasian untuk membantu kami membandingkan ukuran versi, mengekstrak informasi versi, dan operasi lainnya.

Npm juga menggunakan alat ini untuk menangani pekerjaan pembuatan versi.

npm install semver

membandingkan ukuran nomor versi

semver.gt('1.2.3', '9.8.7') // false
semver.lt('1.2.3', '9.8.7') // true

menentukan apakah nomor versi sesuai dengan spesifikasi, dan mengembalikan nomor versi yang memenuhi spesifikasi setelah diurai.

semver.valid('1.2.3') // '1.2.3'
semver.valid('abc') // null

memaksa nomor versi lain ke nomor versi semver

semver.valid(semver.coerce('v2')) // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')) //

Beberapa kegunaan lain dari

'42.6.7'

semver.clean(' =v1.2.3 ') // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // benar
semver.minVersion('>=1.0.0') // '1.0.0'

Di atas adalah penggunaan semver yang paling umum. Untuk detail lebih lanjut, silakan lihat dokumentasi semver: https://github.com/npm/node -semver

2.4 Manajemen versi ketergantungan

Kita sering melihat perbedaan cara menulis berbagai dependensi di package.json :

"dependencies": {
    "sinyal": "1.4.0",
    "figlet": "*",
    "bereaksi": "16.x",
    "tabel": "~5.4.6",
    "yarg": "^14.0.0"
  }

Tiga yang pertama mudah dimengerti:

"signale": "1.4.0" : Nomor versi tetap
"figlet": "*" : Versi apa pun ( >=0.0.0 )
"react": "16.x" : Cocok main Version ( >=16.0.0 <17.0.0 )
"react": "16.3.x" : Cocokkan versi mayor dan versi minor ( >=16.3.0 <16.4.0 )

Mari kita lihat dua yang terakhir, nomor versi Simbol ~ dan ^ dikutip:

~ : Ketika versi baru diperoleh saat menginstal dependensi, instal versi terbaru z di xyz . Artinya, meskipun nomor versi mayor dan nomor versi minor tidak berubah, nomor revisi terbaru tetap dipertahankan.
^ : Ketika versi baru diperoleh saat menginstal dependensi, y dan z di xyz yang diinstal adalah versi terbaru. Artinya, dengan tetap menjaga nomor versi mayor tidak berubah, tetap mempertahankan nomor versi minor dan nomor revisi sebagai versi terbaru.

Ketergantungan yang paling umum dalam file package.json adalah "yargs": "^14.0.0" , karena ketika kita menggunakan npm install package untuk menginstal paket, npm menginstal versi terbaru secara default, dan kemudian menginstalnya di Add tanda ^ sebelum nomor versi.

Perhatikan bahwa jika nomor versi mayor adalah 0 , maka akan dianggap sebagai versi tidak stabil. Situasinya berbeda dari yang di atas:

nomor versi mayor dan nomor versi minor adalah 0 : ^0.0.z dan ~0.0.z keduanya. dianggap sebagai versi tetap, tidak ada perubahan yang akan terjadi saat menginstal dependensi.
Nomor versi utama adalah 0 : ^0.yz berperilaku sama dengan ~0.yz , hanya nomor revisi yang disimpan sebagai versi terbaru.

Nomor versi 1.0.0 digunakan untuk mendefinisikan API publik. Ketika perangkat lunak Anda dirilis ke lingkungan resmi, atau memiliki API yang stabil, Anda dapat merilis versi 1.0.0. Jadi, ketika Anda memutuskan untuk merilis versi resmi paket npm ke dunia luar, tandai versinya sebagai 1.0.0.

2.5 Kunci

file kunci

versi ketergantungan

Dalam pengembangan sebenarnya, masalah aneh sering terjadi karena ketidakkonsistenan dalam berbagai dependensi, atau dalam beberapa skenario, kami tidak ingin dependensi diperbarui. Disarankan untuk menggunakan package-lock.json selama pengembangan.

Mengunci versi ketergantungan berarti kecuali kita melakukan pembaruan secara manual, versi tetap akan diinstal setiap kali kita menginstal ketergantungan. Pastikan seluruh tim menggunakan dependensi dengan nomor versi yang konsisten.

Setiap kali Anda menginstal versi tetap, tidak perlu menghitung rentang versi ketergantungan, yang dapat mempercepat waktu instalasi ketergantungan di sebagian besar skenario.

Saat menggunakan package-lock.json, pastikan versi npm di atas 5.6, karena antara 5.0 dan 5.6, logika pemrosesan package-lock.json diperbarui beberapa kali, dan logika pasca-pemrosesan versi 5.6 secara bertahap stabil.

Kami akan menganalisis struktur detail package-lock.json di bab selanjutnya.

Tujuan kami

memperbarui dependensi secara berkala

adalah untuk memastikan bahwa dependensi yang digunakan dalam tim konsisten atau stabil, daripada tidak pernah memperbarui dependensi tersebut.

Dalam skenario pengembangan sebenarnya, meskipun kami tidak perlu menginstal versi baru setiap saat, kami masih perlu memutakhirkan versi ketergantungan secara rutin sehingga kami dapat menikmati perbaikan masalah, peningkatan kinerja, dan pembaruan fitur baru yang dihasilkan oleh peningkatan paket ketergantungan.

Menggunakan npm outdated dapat membantu kami membuat daftar dependensi yang belum ditingkatkan ke versi terbaru:

kuning berarti tidak memenuhi rentang versi semantik yang kami tentukan - tidak perlu ditingkatkan
; merah berarti memenuhi rentang versi semantik yang ditentukan - perlu ditingkatkan

dan jalankan npm update . Tingkatkan semua dependensi merah.

2.6 Praktik Terbaik untuk Pemilihan Versi Dependen

Rilis Versi

Saat menerbitkan versi resmi paket npm secara eksternal, tandai versinya sebagai 1.0.0 .
Setelah versi paket dirilis, modifikasi apa pun harus dirilis sebagai versi baru.
Nomor versi diberi nama secara ketat dalam format主版本号.次版本号.修订号
yang dirilis harus bersifat inkremental.
Saat merilis versi mayor atau ketika perubahan versi besar, rilis alpha、beta、rc dan versi lanjutan lainnya terlebih dahulu.

Pilih

~ ketergantungan proyek utama
.
Ada banyak sub-modul, yang semuanya merupakan paket npm yang dikembangkan oleh anggota tim dependensi proyek utama harus ditingkatkan setiap kali sub-dependensi diperbarui, yang sangat rumit. Jika sub-dependensi sepenuhnya Percaya, buka langsung ^ Tingkatkan ke versi terbaru setiap saat.
Proyek utama berjalan di jalur docker , dan sub-dependensi masih dikembangkan dan ditingkatkan secara lokal Sebelum versi docker dirilis, semua versi ketergantungan harus dikunci untuk memastikan bahwa tidak akan ada masalah online setelah sub-dependensi lokal dikunci. dilepaskan.

Pertahankan konsistensi dependensi

, pastikan versi npm di atas 5.6 , dan pastikan file package-lock.json diaktifkan secara default.
Setelah npm inatall dijalankan oleh anggota inisialisasi, package-lock.json dikirimkan ke gudang jarak jauh. Jangan mengirimkan node_modules langsung ke repositori jarak jauh.
Jalankan npm update secara teratur untuk meningkatkan dependensi, dan kirimkan file lock untuk memastikan bahwa anggota lain memperbarui dependensi mereka secara bersamaan. Jangan mengubah file lock secara manual.

Perubahan ketergantungan dan

peningkatan ketergantungan: Ubah versi ketergantungan file package.json dan jalankan npm install
lock
versi dependensi: Langsung jalankan npm install package@version (mengubah package.json tidak akan menurunkan versi dependensi).
setelah mengubah dependensi.

3. Analisis prinsip instalasi npm

npm install mungkin akan melalui proses di atas. Bab ini akan membahas tentang detail implementasi, pengembangan, dan alasan setiap proses.

3.1 Struktur bersarang

Kita semua tahu bahwa setelah mengeksekusi npm install , paket dependen diinstal ke dalam node_modules . Mari kita lihat lebih dekat mekanisme spesifik yang digunakan npm untuk menginstal paket dependen ke dalam node_modules .

Pada versi awal npm , cara npm menangani dependensi sederhana dan kasar. Ia menginstal dependensi ke masing-masing node_modules secara rekursif dan ketat sesuai dengan struktur package.json dan struktur package.json dari paket sub-dependensi. Hingga ada paket sub-dependen yang tidak lagi bergantung pada modul lain.

Misalnya, modul my-app sekarang bergantung pada dua modul: buffer dan ignore :

{
  "nama": "aplikasi saya",
  "ketergantungan": {
    "penyangga": "^5.4.3",
    "abaikan": "^5.1.4",
  }
}

ignore adalah modul JS murni yang tidak bergantung pada modul lain, dan buffer bergantung pada dua modul berikut: base64-js dan ieee754 .

{
  "nama": "penyangga",
  "ketergantungan": {
    "base64-js": "^1.0.2",
    "ieee754": "^1.1.4"
  }
}

Kemudian setelah mengeksekusi npm install , struktur direktori modul pada node_modules yang diperoleh adalah sebagai berikut:

Keuntungan dari pendekatan ini jelas. Struktur node_modules sesuai dengan struktur package.json satu-ke-satu, struktur hierarki jelas, dan struktur direktori setiap instalasi dijamin sama.

Namun, bayangkan saja, jika Anda bergantung pada banyak modul, node_modules Anda akan sangat besar dan level sarangnya akan sangat dalam:

Ketergantungan pada tingkat yang berbeda mungkin merujuk pada modul yang sama, sehingga mengakibatkan banyak redundansi.
Dalam sistem Windows , panjang jalur file maksimum adalah 260 karakter, dan tingkat penumpukan yang terlalu dalam dapat menyebabkan masalah yang tidak terduga.

3.2 Struktur datar

Untuk mengatasi masalah di atas, NPM melakukan pembaruan besar-besaran di versi 3.x Ini mengubah struktur bersarang awal menjadi struktur datar:

saat memasang modul, terlepas dari apakah itu ketergantungan langsung atau sub-ketergantungan, modul tersebut pertama kali diinstal di direktori root node_modules .

Masih dengan struktur ketergantungan di atas, kita akan mendapatkan struktur direktori berikut setelah mengeksekusi npm install :

Saat ini, jika kita mengandalkan versi [email protected] di modul:

{
  "Nama": "App saya",
  "ketergantungan": {
    "buffer": "^5.4.3",
    "Abaikan": "^5.1.4",
    "base64-js": "1.0.1",
  }
}

Saat menginstal ke modul yang sama, tentukan node_modules versi modul yang diinstal cocok dengan rentang versi modul baru.

Pada titik ini, kami akan mendapatkan struktur direktori berikut setelah menjalankan npm install :

Sejalan dengan itu, jika kami merujuk pada modul dalam kode proyek, proses pencarian modul adalah sebagai berikut:

Cari
di
bawah jalur modul saat
node_modules
node_modules
node_modules global

[email protected] buffer2@^5.4.3

Oleh karena itu, versi npm 3.x tidak sepenuhnya menyelesaikan masalah redundansi modul dari versi lama, dan bahkan dapat membawa masalah baru.

Bayangkan bahwa aplikasi Anda tidak bergantung pada versi [email protected] , tetapi Anda juga bergantung pada buffer dan buffer2 yang bergantung pada versi base64-js yang berbeda. Karena ketika menjalankan npm install , dependensi dalam package.json diuraikan secara berurutan, urutan di mana buffer dan buffer2 ditempatkan di package.json menentukan struktur ketergantungan node_modules :

bergantung pada buffer2 pertama:

Bergantung pada buffer terlebih dahulu:

Selain itu, untuk memungkinkan pengembang menggunakan paket ketergantungan terbaru di bawah premis keselamatan, kami biasanya hanya mengunci versi besar dalam package.json , yang berarti bahwa setelah versi minor dari beberapa paket ketergantungan diperbarui, struktur ketergantungan mungkin juga diubah.

3.3 File Kunci

Untuk menyelesaikan masalah ketidakpastian npm install , file package-lock.json ditambahkan dalam versi npm 5.x , dan metode instalasi juga mengikuti metode datar npm 3.x

Fungsi package-lock.json node_modules package-lock.json npm install struktur ketergantungan. .

Misalnya, kami memiliki struktur ketergantungan berikut:

{
  "Nama": "App saya",
  "ketergantungan": {
    "buffer": "^5.4.3",
    "Abaikan": "^5.1.4",
    "base64-js": "1.0.1",
  }
}

package-lock.json yang dihasilkan setelah menjalankan npm install adalah sebagai berikut:

{
  "Nama": "App saya",
  "versi": "1.0.0",
  "ketergantungan": {
    "base64-js": {
      "Versi": "1.0.1",
      "Terselesaikan": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz",
      "Integritas": "sha1-asbrszt7xze47tutdw3i/np+pag ="
    },
    "buffer": {
      "Versi": "5.4.3",
      "Terselesaikan": "https://registry.npmjs.org/buffer/-/buffer-5.4.3.tgz",
      "Integritas": "SHA512-ZVJ65TKFEIT3I6AJ5BIVJDZJJJQQGS4O/SNOEZG1F1KYAP9NU2JCUDPWZRSJTHMZG0H7BZKN4RNQPIMHUXWX2A ==",
      "memerlukan": {
        "base64-js": "^1.0.2",
        "IEEE754": "^1.1.4"
      },
      "ketergantungan": {
        "base64-js": {
          "Versi": "1.3.1",
          "Terselesaikan": "https://registry.npmjs.org/base64-js/-/base64-js-1.3.1.tgz",
          "Integritas": "SHA512-MLQ4I2QO1YTVGWFWMCNGKO // JXAQUEZVWEKTJGQFM4JIK0KU+YTMFPLL8J+N5MSPOFJHWOAG+9YHB7BWAHM36G =="
        }
      }
    },
    "IEEE754": {
      "Versi": "1.1.13",
      "Terselesaikan": "https://registry.npmjs.org/ieee754/-/ieee754-1.1.13.tgz",
      "Integritas": "sha512-4vf7i2lyv/hawerso3xmlmkp5ez83i+/cdluxi/igts/o1sejbnhttnxzmrzfvouqj7lzjqhketvpgsfdlwztg =="
    },
    "mengabaikan": {
      "Versi": "5.1.4",
      "Terselesaikan": "https://registry.npmjs.org/ignore/-/ignore-5.1.4.tgz",
      "Integritas": "SHA512-MZBUSAHKTW1U7JPKJY7LCARD1FU5W2RLDXLM4KDKAYUCWZIMJKPLUF9CM1AlEWYJGUPDQEWLAM18Y6AU69A8A =="
    }
  }
}

Mari kita lihat lebih dekat pada struktur di atas:

Dua name dan version atribut terluar sama dengan name dan version di package.json , dan digunakan untuk menggambarkan nama paket dan versi saat ini.

dependencies adalah key , yang sesuai dengan struktur node_modules

resolved
version node_modules
?
integrity hash Subresource Integrity
requires dependencies package.json ketergantungan.json.
dependencies : Strukturnya sama dengan struktur dependencies luar, dan menyimpan paket ketergantungan yang dipasang di sub-dependensi node_modules .

Perhatikan di sini bahwa tidak semua sub-dependensi memiliki atribut dependencies node_modules

Misalnya, tinjau dependensi di atas:

Versi [email protected] yang kami andalkan dalam konflik my-app dengan base64-js@^1.0.2 yang kami andalkan dalam buffer , jadi [email protected] perlu diinstal di node_modules dari node_modules of the Paket buffer , sesuai dengan atribut dependencies buffer di package-lock.json telah diubah. Ini juga sesuai dengan pendekatan datar npm untuk dependensi.

Oleh karena itu, menurut analisis di atas, file package-lock.json package-lock.json struktur direktori node_modules berada dalam korespondensi satu-ke-satu. dihasilkan oleh setiap instalasi yang sama.

Selain itu, penggunaan package-lock.json dalam proyek dapat secara signifikan mempercepat waktu pemasangan ketergantungan.

Kami menggunakan npm i --timing=true --loglevel=verbose lock lock proses npm install yang lengkap. Bersihkan cache npm sebelum membandingkan.

Tanpa menggunakan file lock :

Gunakan file lock :

Dapat dilihat bahwa versi spesifik dan tautan unduhan dari setiap paket telah di-cache di package-lock.json . sejumlah besar permintaan jaringan.

Saat

menggunakan rekomendasi

untuk mengembangkan aplikasi sistem, disarankan untuk mengirimkan file package-lock.json ke repositori versi kode untuk memastikan bahwa versi ketergantungan yang diinstal oleh semua pengembang tim dan tautan CI konsisten saat menjalankan npm install .

Saat semver paket npm , paket npm Anda harus bergantung pada repositori lain dalam ruang lingkup, yang akan menyebabkan redundansi yang tidak perlu. Jadi kita tidak boleh mempublikasikan file package-lock.json ( npm tidak akan mempublikasikan file package-lock.json secara default).

3.4 Caching

Setelah menjalankan npm install atau perintah npm update untuk mengunduh dependensi, selain menginstal paket ketergantungan di direktori node_modules , salinan juga akan di -cache di direktori cache lokal.

Anda dapat menanyakannya melalui npm config get cache : Di Linux atau Mac standarnya adalah direktori .npm/_cacache di direktori home pengguna.

tar tar direktori di direktori ini hash content-v2 content-v2 index-v5 index-v5

Saat NPM menjalankan instalasi, ia dapat menghasilkan key unik yang sesuai dengan catatan cache di direktori index-v5 berdasarkan integrity、version、name yang disimpan dalam package-lock.json , dengan demikian menemukan hash dari paket tar , Dan kemudian mencarinya berdasarkan hash tar

Kami dapat menemukan paket untuk mencari dan menguji di direktori cache, dan mencari jalur paket di index-v5 :

grep "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1. TGZ "-R Index -V5

Lalu kami memformat JSON:

{
  "Key": "Pacote: Version-manifest: https: //registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz: sha1-asbrszt7xze47tutdw3i/np+pag =",, ","
  "Integritas": "SHA512-C2EKHXWXVLSBRUCJTRS3XFHV7MF/Y9KLMKDXPTE8YEVCOH5H8AE69Y+/LP+AHPW91CRNZGO78ELOK2E6APJFIQ =="
  "Waktu": 1575554308857,
  "Ukuran": 1,
  "metadata": {
    "id": "[email protected]",
    "tampak": {
      "Nama": "base64-js",
      "Versi": "1.0.1",
      "mesin": {
        "Node": "> = 0.4"
      },
      "Dependencies": {},
      "OpsionalDependencies": {},
      "DevDependencies": {
        "Standar": "^5.2.2",
        "Tape": "4.x"
      },
      "Bundledependencies": False,
      "Peerdependencies": {},
      "usang": false,
      "_resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz",
      "_integrity": "sha1-asbrszt7xze47tutdw3i/np+pag =",
      "_shasum": "6926d1b194fbc737b8eed513756de2fcda7ea408",
      "_shrinkwrap": null,
      "bin": null,
      "_id": "[email protected]"
    },
    "Type": "Finalisasi-Manifest"
  }
}

Atribut _shasum di atas 6926d1b194fbc737b8eed513756de2fcda7ea408 adalah hash dari paket tar , dan beberapa digit pertama 6926 dari hash adalah dua tingkat Direktori yang di -Cached.

Strategi caching di atas dimulai dari versi NPM V5. }.

npm menyediakan beberapa perintah untuk mengelola data cache:

npm cache add : Penjelasan resmi adalah bahwa perintah ini terutama digunakan secara internal oleh npm , tetapi juga dapat digunakan untuk secara manual menambahkan cache ke paket yang ditentukan.
npm cache clean --force Hapus semua data di direktori cache.
npm cache verify : Verifikasi validitas dan integritas data yang di -cache dan bersihkan data sampah.

Berdasarkan data yang di-cache, NPM menyediakan mode instalasi offline, yaitu sebagai berikut:

--prefer-offline : Gunakan data yang di-cache terlebih dahulu.
--prefer-online : Prioritaskan penggunaan data jaringan.
--offline : Jangan meminta jaringan dan menggunakan data yang di-cache secara langsung.

3.5 Integritas File

Kami menyebutkan integritas file berkali -kali di atas, jadi apa itu verifikasi integritas file?

tarball shasum paket ketergantungan, kita biasanya bisa hash nilai hash yang dihitung oleh npm npm info paket ketergantungan.

Setelah pengguna mengunduh paket ketergantungan secara lokal, ia perlu memastikan hash hash ada kesalahan yang terjadi selama proses pengunduhan. Sama, pastikan bahwa ketergantungan yang diunduh selesai.

3.6

Sekarang proses keseluruhan selesai, mari kita ringkas proses di atas:

Periksa file .npmrc : prioritasnya adalah: file .npmrc tingkat-level> file .npmrc tingkat pengguna> file .npmrc tingkat global> npm bawaan npm bawaan npm built-in npm npm npm npm File .npmrc
Periksa apakah ada file lock dalam proyek.
No lock File:
- Dapatkan informasi paket dari gudang jarak jauh npm
- dan bangun pohon
  - ketergantungan
  berdasarkan package.json .
  - di direktori root node_modules .
  - Saat menghadapi modul yang sama, dinilai apakah versi modul yang telah ditempatkan di pohon ketergantungan cocok dengan kisaran versi modul baru. di bawah node_modules dari modul saat ini.
- - pohon
- - ketergantungan logis, bukan instalasi yang sebenarnya
- - Tidak Ada Cache:
    - Dari npm Paket unduhan gudang jarak jauh
    - gagal untuk
      - memverifikasi
    - integritas paket
    - verifikasi dan lulus:
      - Salin paket yang diunduh ke direktori cache npm
      - dan ekstrak paket yang diunduh ke node_modules sesuai dengan ketergantungan sesuai dengan ketergantungan sesuai dengan node.
lock
- package-lock.json package.json
- - - - Ekstrak
  - cache ke node_modules sesuai dengan struktur
- lock
- node_modules
- package-lock.json .
- Jika tidak ada konflik, lewati langsung proses mendapatkan informasi paket dan membangun pohon ketergantungan, dan mulai mencari informasi paket dalam cache.

Proses di atas secara singkat menjelaskan proses umum npm install npm install package --timing=true --loglevel=verbose Proses instalasi dan detail paket tertentu.

3.7 benang

yarn dirilis pada 2016 package-lock.json waktu itu, npm masih dalam periode V3 . pengembang. Pada titik ini, yarn lahir:

Di atas adalah keuntungan dari yarn yang disebutkan di situs web resmi, yang masih sangat menarik pada waktu itu. Tentu saja, npm lock menyadari masalahnya yarn yarn membuat banyak optimasi. Desain masih sangat bagus.

yarn juga menggunakan struktur datar yarn.lock npm v3 untuk mengelola yarn.lock

. Adalah file autogenerasi.
# YARN LOCKFILE V1


[email protected]:
  Versi "1.0.1"
  diselesaikan "https://registry.yarnpkg.com/base64-js/-/base64-js-1.0.1.tgz#6926d1b194fbc737b8eed513756de2fcda7ea408" "
  integritas sha1-asbrszt7xze47tutdw3i/np+pag =

base64-js@^1.0.2:
  Versi "1.3.1"
  Terselesaikan "https://registry.yarnpkg.com/base64-js/-/base64-js-1.3.1.tgz#58ece8cb75dd07e71ed08c736abc5fac4dbf8df1" "
  Integritas SHA512-MLQ4I2QO1YTVGWFWMCNGKO // JXAQUEZVWEKTJGQFM4JIK0KU+ytmfpll8j+n5mspofjhwoag+9yhb7bahm36g ==

buffer@^5.4.3:
  Versi "5.4.3"
  diselesaikan "https://registry.yarnpkg.com/buffer/-/buffer-4.4.3.tgz#3fbc9c69eb713d323e3fc1a895EEE0710C072115" "
  Integritas SHA512-ZVJ65TKFEIT3I6AJ5BIVJDZJJQQGS4O/SNOEZG1F1KYAP9NU2JCUDPWZRSJTHMMZG0H7BZKNKN4RNQPIMHUXWX2A ==
  ketergantungan:
    base64-js "^1.0.2"
    IEEE754 "^1.1.4"

IEEE754@^1.1.4:
  Versi "1.1.13"
  diselesaikan "https://registry.yarnpkg.com/ieee754/-/ieee754-1.1.13.tgz#ec168558e95aa181fd87d37f55c32bbcb6708b84"
  Integritas SHA512-4VF7I2LYV/HAWERSO3XMLMKP5EZ83I+/CDLUXI/IGTS/O1SEJBNHTTNXZMRZFVOUQJ7LZJQHKETVPGSFDLWZTG ==

abaikan@^5.1.4:
  Versi "5.1.4"
  diselesaikan "https://registry.yarnpkg.com/ignore/-/ignore-5.1.4.tgz#84b7b3dbe6452b6ef0eca99f6743dbec6d97adf"

Integritas SHA512

package-lock.json

MZBUSAHKTW1U7JPKJY7LCARD1FU5W2RLDXLM4KDKAYUCWZIMJKPLUF9CM1AlLEWYJGUPDQEWLAM18Y6AU6A8A

yarn.lock json package-lock.json
yarn.lock Nomor versi ketergantungan neutron yarn.lock tidak diperbaiki, yang berarti bahwa yarn.lock saja tidak dapat menentukan struktur direktori node_modules dan perlu dikoordinasikan dengan file package.json . Dan package-lock.json hanya perlu satu file untuk ditentukan.

Strategi caching yarn terlihat sangat mirip dengan itu sebelum npm v5 . Gunakan Command yarn cache dir untuk melihat direktori data yang di -cache:

Secara default, yarn menggunakan mode prefer-online , yang berarti data jaringan digunakan terlebih dahulu.

Ringkasan:

Saya berharap bahwa setelah membaca artikel ini, ini akan membantu Anda sebagai berikut:

npm
konfigurasi terperinci di pacakge.json untuk memiliki wawasan lebih lanjut tentang konfigurasi rekayasa proyek.
Versi
package-lock.json Memahami instalasi npm npm install