Saya tidak yakin apakah ini layak, atau apakah itu termasuk dalam repo Node.js.
Sering ada kasus di mana dependensi tertentu memerlukan konfigurasi build khusus agar berfungsi dengan baik di semua lingkungan (misalnya).
Konfigurasi ini mungkin konfigurasi Babel, konfigurasi Webpack, atau sesuatu yang khusus hanya untuk paket itu.
Seperti yang ada saat ini, tidak ada cara standar untuk mengonfigurasi paket.
Beberapa orang menggunakan konvensi di mana mereka menempatkan bidang di package.json
dinamai paket, dan paket dapat membacanya. Tapi rasanya tidak cukup standar.
Ketika sebuah paket membutuhkan konfigurasi khusus untuk runtime atau waktu pembuatan.
Terkadang JavaScript membutuhkan langkah-langkah pembuatan untuk kasus-kasus tertentu. Fitur konfigurasi ini akan memiliki opsi "membangun dependensi" opsional yang dapat diteruskan ke paket apa pun (apakah mereka membuat modul asli, atau hanya mentranspile JavaScript ke bentuk yang lebih rendah).
Bergantung pada konfigurasi, sebuah paket mungkin memerlukan dependensi tertentu yang jika tidak demikian tidak akan diperlukan (fe build dependensi).
Jadi sistem paket akan cukup pintar, karena jika pengguna memiliki konfigurasi paket tertentu, ia dapat menentukan dependensi tambahan mana yang akan diinstal.
Mungkin fitur ini hanya perlu diperluas dari sistem modul asli yang ada ke sistem JavaScript secara keseluruhan (dengan cara yang mudah digunakan, modul asli itu rumit).
Ini juga bisa sangat berguna untuk hal-hal seperti dependensi opsional. Akan mudah, dengan konfigurasi, untuk menentukan bahwa perpustakaan menggunakan (misalnya) three
alih-alih babylonjs
. Ini akan menyebabkan ketergantungan yang sesuai untuk diinstal. Ini mirip dengan dependensi rekan, tetapi lebih mudah, dan paket tertentu yang bergantung pada deps opsional akan memiliki cara standar untuk mengakses API konfigurasi dengan andal untuk menentukan apakah kondisi tertentu ditentukan (saat ini rumit, dan setiap cystom traversal node_modules non- standar dalam kasus ini).
Sebagai contoh lain, terkadang konsumen paket perlu menggunakan sumber paket alih-alih keluaran terkompilasi yang biasa untuk mengkompilasi kode dengan cara yang berbeda (biasanya bagi saya, saya ingin melakukan ini dengan Webpack).
Secara umum ada masalah dengan hal semacam itu, yang sejauh ini NPM tidak memberikan cara penanganan yang umum.
pembuat paket dan penggunanya
Fitur ini akan memungkinkan pembuat paket, dengan cara standar, untuk menambahkan fitur ke paket mereka di mana mereka dapat mengatakan "Oh, Anda ingin CSS menjadi eksternal alih-alih built-in ke dalam file paket biasa, tidak masalah, tambahkan saja- dan-opsi tersebut dalam konfigurasi proyek Anda, maka paket ini akan secara otomatis mengeluarkan CSS apa pun dari outputnya", dan kemudian dengan konfigurasi standar itu, pembuat paket dapat menggunakan Webpack, Babel, atau alat apa pun yang diinginkan, untuk mencapai hasil.
Dalam pengertian ini, semua paket akan memiliki beberapa cara standar yang memungkinkan pengguna untuk mengomunikasikan opsi kepada mereka, di mana opsi dapat menentukan rangkaian dependensi alternatif atau langkah-langkah pembuatan, terlepas dari file sumber atau alat pembangunan apa yang digunakan paket.
Akan ada konfigurasi di sisi pengguna, tetapi opsi tersebut akan memetakan ke konfigurasi di sisi paket yang akan menentukan dependensi (dan karenanya membangun alat) untuk dijalankan selama instalasi, atau serupa.
Saya dapat melihat sebagian besar paket kemudian mengirimkan output kode sumber default, dan beberapa pengguna menyesuaikannya.
Sering terjadi bahwa cara terbaik untuk mendapatkan kode sumber TypeScript untuk dikompilasi, dengan fitur lengkap yang tidak dibatasi oleh file deklarasi emit , adalah dengan mengirimkan kode sumber TypeScript mentah, dan mentranspilenya di sisi konsumen. Konvensi konfigurasi akan sangat membantu dalam hal ini.
TypeScript menyatakan bahwa konsumen tidak boleh mengubah sumber TypeScript, tetapi mereka telah menggali lubang di mana itu bisa menjadi kebutuhan karena masalah terkait itu. Saya hanya menggunakannya sebagai satu contoh di mana standar konfigurasi bisa sangat berguna.
Fitur ini akan luar biasa karena terkadang pengembang menghadapi banyak kesulitan dalam memperbaiki masalah semacam ini.
Komentar yang paling membantu
Fitur ini akan luar biasa karena terkadang pengembang menghadapi banyak kesulitan dalam memperbaiki masalah semacam ini.