Ada banyak paket webpack yang menemukan duplikat dalam bundel, yang paling populer di antaranya adalah duplikat-paket-pemeriksa-webpack-plugin , tetapi itu memerlukan pemasangan kembali proyek, dan karena ada tugas untuk mengotomatiskan pemilihan versi paket yang optimal, ternyata solusi alternatifnya sendiri.
Nah, atau cerita saya adalah bagaimana ternyata mengurangi bundel sebesar 15%, dalam beberapa detik.
Seperti di banyak perusahaan besar yang memiliki basis kode besar, ada banyak logika umum, akibatnya kami menggunakan komponen umum yang diterbitkan dalam repositori npm kami. Mereka diterbitkan melalui lerna , masing-masing, sebelum setiap instalasi atau pembaruan komponen umum, muncul pertanyaan tentang versi mana yang akan diinstal. lerna menimpa semua komponen yang menggunakan komponen yang diterbitkan (jika versi sebelumnya adalah yang terbaru). Oleh karena itu, selalu ada versi beberapa komponen yang lebih cocok satu sama lain, karena mereka tidak bersaing dengan ketergantungan.
Dari proyek open source dengan cara nivo ini , inilah konfigurasi lerna mereka .
Bagaimana dependensi duplikat muncul? Dan bagaimana cara menghilangkannya?
Misalkan Anda memiliki proyek sederhana dengan package.json berikut:
{ "name": "demo-project", "version": "1.0.0", "dependencies": { "@nivo/bar": "0.54.0", "@nivo/core": "0.53.0", "@nivo/pie": "0.54.0", "@nivo/stream": "0.54.0" } }
Mari kita lihat di mana @nivo/core :
npm list @nivo/core
Kita melihat 4 salinan @nivo/core (3 salinan 0.54.0 dan 1 - 0.53.0 ). Tetapi jika kita mengubah versi minor @nivo/core menjadi 0.54.0 , duplikat akan dihilangkan.
Contoh saat ini sederhana, tetapi dalam praktiknya, tentu saja, setiap paket memiliki lebih banyak dependensi, dan Anda masih perlu mempertimbangkan dependensi lebih lanjut, yang meningkatkan kompleksitas tugas.
Dan sekali lagi melihat ukuran bundel yang sangat besar, saya lelah secara manual menghapus paket duplikat.
Secara umum, berhak untuk segera memutakhirkan paket ke versi terbaru, tetapi tidak ada waktu, seperti biasa, untuk mengubah versi utama, dan itu lama dan sulit untuk memilih paket yang sesuai dengan pencarian buta. Setelah semua, Anda perlu memperbarui versi dependensi di package.json , instal dependensi baru, dan kemudian periksa apakah duplikat telah menghilang dalam build, jika tidak, ulangi, untuk waktu yang lama, rata-rata, 3-4 menit per iterasi.
Semua ini monoton dan membutuhkan perhatian, jadi saya memutuskan untuk mengotomatisasi.
Saya ingin tahu duplikat tanpa menginstal ulang dependensi, dan membangun kembali proyek, idealnya aplikasi cli yang menampilkan opsi optimasi dalam 10 detik dan semua duplikat yang ada dalam proyek.
Penghapusan take dapat dibagi menjadi beberapa subtugas, kami akan mempertimbangkannya secara berurutan.
Tugas pertama. Anda perlu memodelkan pohon dependensi bundel masa depan hanya dengan package.json, mengingat dedupe standar, dengan cepat, tidak lebih dari 100ms.
Saya memutuskan untuk menggunakan paket-json untuk mendapatkan informasi tentang paket dan semver untuk membandingkan versi yang berbeda.
Hasilnya adalah dependensi paket npm -tree-builder , dengan cerdas memodelkan pohon dependensi bundel hanya dengan package.json.
Dialokasikan ke komponen yang terpisah, karena mungkin seseorang akan menggunakannya kembali dalam tugas kombinatorial dengan package.json.
Tugas kedua. Tugas kombinatorial, penghitungan opsi yang efisien untuk mengubah dependensi, dan perbandingan beberapa opsi untuk pohon, dan tentu saja, pilihan yang optimal.
Kami harus entah bagaimana membandingkan pohon yang dihasilkan secara kualitatif, dan kami harus meminjam ide entropi, sebagai ukuran kuantitatif gangguan, mengambil jumlah salinan rangkap (dari contoh di atas adalah 3).
Akan bagus untuk mempertimbangkan bobot paket (dalam KB), tetapi sayangnya saya tidak menemukan paket yang dapat bekerja dengan cepat dengan bobot, dan paket yang berfungsi bekerja sekitar setengah menit per paket, misalnya ukuran paket . Karena mereka bekerja sesuai dengan prinsip berikut: membuat proyek dengan ketergantungan tunggal, membangun dependensi, setelah itu berat total folder diukur. Akibatnya, saya tidak menemukan kriteria lain, karena jumlah salinan rangkap.
Untuk memahami paket mana yang perlu diubah, alasan duplikat, lebih spesifik sumber dan efek, dipertimbangkan. Pencacahan menghilangkan efek duplikat sebanyak mungkin, dan karena efeknya dihilangkan, kemudian duplikat juga.
Sebagai hasilnya , kami mendapat aplikasi kecil cli ostap yang merekomendasikan versi optimal untuk mengurangi jumlah instance duplikat dalam bundel.
Itu dimulai hanya dengan menunjuk ke package.json dari proyek Anda.
ostap ./package.json
Anda juga dapat menggunakannya untuk dengan cepat melihat semua pengambilan di masa depan tanpa membangun kembali proyek dengan hanya mengubah versi di package.json.
ostap ./package.json -s
Akibatnya, dalam proyek saya, berat total bundel berkurang 15%.
Repositori memiliki bagian mulai cepat.
Jika Anda menggunakan pemisahan rute, mungkin tampak bahwa beberapa bundel telah bertambah berat, tetapi distribusi komponen mungkin telah berubah. Artinya, alih-alih salinan dependensi pada setiap halaman, satu-satunya versi berubah menjadi bundel umum untuk semua halaman, jadi Anda perlu mengevaluasi berat total bundel untuk semua halaman.
Semoga artikel ini bermanfaat. Dan seseorang akan menghemat informasi waktu. Terima kasih
Referensi untuk kenyamanan lagi:
- Paket memodelkan pohon dependensi bundel oleh package.json
Github - Ketergantungan Pengoptimal untuk menghilangkan duplikat dalam satu bundel
Github
Jika Anda memiliki ide menarik, tulis untuk diterbitkan di github, kami akan membahasnya.