Yarn: Tambahkan cara untuk menginstal dependensi peer paket untuk pengembangan / pengujian

@ jpollard-cs Saya tidak bermaksud menambahkan paket sebagai dependensi peer, saya mengacu pada memiliki sarana untuk menginstal semua paket yang saat ini terdaftar sebagai dependensi peer.
Jika tidak, tidak ada cara yang layak untuk mengembangkan plugin.

npm install
Akan menginstal semua paket yang dideklarasikan di bagian dependensi package.json.

yarn add --peer
Saya mengharapkan ini untuk menginstal semua paket yang dideklarasikan di bagian peerDependencies package.json.

Apakah ada cara untuk menginstal paket yang dideklarasikan di peerDependencies?

Kasus penggunaan saya adalah pengembangan / pengujian modul react native.

Berikut masalah NPM, yang mereka tutup: https://github.com/npm/npm/issues/11213

Rupanya tidak penting bagi pengembang NPM.

+1 ini penting untuk penulis perpustakaan

Saya sudah menulis ini tentang masalah NPM, tetapi untuk orang-orang Yarn:

Saya menulis program cli menginstal dependensi peer paket:

# If you're using npm
npm install -g install-peerdeps

# If you're using yarn
yarn global add install-peerdeps

cd my-project-directory

install-peerdeps <package>[@<version>]

# for example
install-peerdeps @angular/core
# will install all of angular's peerdeps

Jika Anda memiliki masalah dengan itu, buka masalah di repo!

@nathanhleung , paket itu tampaknya menginstal semua dependensi peer dependensi Anda. Yang tidak tepat tentang tiket ini. Ini tentang menginstal dependensi peer paket Anda sendiri.

Saya telah memperbaikinya dengan paket untuk melakukannya https://www.npmjs.com/package/@team-griffin/install -self-peers

@nathanung Anda

Hmm ... Jika seseorang membutuhkan dependensi untuk pengembangan / pengujian, bukankah seharusnya ia menempatkannya di bawah devDependencies ? Tidak mencoba menjatuhkan bom atau apapun ...

@nikolakanacki Benar-benar melihat dari mana Anda berasal, menurut saya yang aneh adalah bahwa itu akan menjadi ketergantungan sesama dan ketergantungan dev, karena Anda tidak boleh memaksa konsumen Anda memasang ketergantungan dev Anda. Saya memberikan suara agar mudah menginstal rekan!

@nikolakanacki Jika Anda membuat paket yang bergantung pada paket lain yang diinstal pengguna, Anda tidak menginginkannya di devDependencies, yang dapat menghasilkan duplikat paket tersebut dalam versi yang berbeda., dan tidak masuk akal dalam beberapa kasus. ...

Gunakan case eslint-find-rules

Paket mencari aturan yang tersedia di ESLint yang tidak dikonfigurasi di konfigurasi Anda.
Agar masuk akal bagi pengguna, ia perlu memeriksa paket ESLint yang mereka instal, dan bukan versi spesifik yang disertakan dengan paket Anda (atau latest ).
Jadi, ini adalah ketergantungan peer .

Sekarang jika Anda ingin berkontribusi pada proyek, Anda ingin ESLint diinstal di node_modules sehingga Anda dapat menguji kode Anda, tanpa melakukan npm-link dengan proyek dummy yang menginstal ESLint.

Ketika pengguna menjalankan yarn , sistem tidak boleh menginstal peer deps dan memperingatkan bahwa mereka tidak ada (ini berfungsi).

Jadi ... sebuah flag yang membuat thread install peer deps jika belum dipasang akan dengan baik mengatasi masalah itu.

Hal yang menarik

• yarn add <package> --peer menginstalnya ke node_modules dan menambahkannya ke package.json
• yarn add <other_package> setelah itu menghapus paket yang diinstal dari node_modules

Saat ini saya mengikuti model @nikolakanacki dan sepertinya berhasil. Saya setuju itu bisa membingungkan dan saya lebih suka yarn install --peer untuk menginstal dependencies , devDependencies dan peerDependencies tetapi ini bekerja sama baiknya untuk saya.

Jika saya mendapatkan hak ini @kyleholzinger / @gaastonsr , Anda tidak ingin menginstal peerDependencies dalam mode pengembangan ( cd -ed ke dalam repo / paket yang memiliki peerDependencies , clone baru, perlu dikembangkan pada deps peer tersebut) tetapi tambahkan ke proyek target setelah Anda menginstal paket yang memiliki deps peer?

Untuk memperjelas: Anda menginstal eslint-find-rules yang mengeluh bahwa Anda membutuhkan eslint sebagai ketergantungan (ini adalah peerDependency dari eslint-find-rules ), jadi sekarang Anda menginginkan cara yang mudah menambahkan dependensi tersebut ke dalam peer yang sedang Anda kerjakan (proyek saat ini yang bergantung pada eslint-find-rules )? Sesuatu seperti "Selesaikan dan tambahkan sebagai dependensi baru (modifikasi package.json dan yarn.lock ) dependensi peer paling cocok yang dibutuhkan dependensi saya saat ini"?

Jika ini maksud Anda, ini bisa sangat berguna, saya pikir Anda mengacu pada menginstalnya secara otomatis saat mengembangkan.

Fitur ini dapat diperkenalkan untuk lebih dari sekadar kenyamanan, misalnya: beberapa dependensi dapat bergantung pada paket yang sama dari target peer, tetapi memerlukan versi berbeda - fitur ini dapat memanfaatkannya dengan mencoba menyelesaikannya menjadi satu yang terbaik -mencocokkan target (jika memungkinkan).

Sesuatu untuk dipikirkan dengan pasti.

Jika ini maksud Anda, ini bisa sangat berguna, saya pikir Anda mengacu pada menginstalnya secara otomatis saat mengembangkan.

Inilah yang saya cari. Menginstal peerDependencies saat saya mengembangkan sebuah paket.

Iya persis @nikolakanacki! Saya merasa ada peluang besar bagi kami untuk membantu orang-orang mengelola departemen sebaya mereka.

@gaastonsr perlu menambahkannya ke devDependencies lalu - sesederhana itu. Jika tidak, paket Anda rusak untuk pengembangan. Setelah Anda mengkloning proyek dan menjalankan yarn - semuanya harus diinstal dan Anda harus dapat menjalankan pengujian, dll.

Dua pertanyaan sederhana dan sama sekali tidak berhubungan yang harus ditanyakan sebelum menginstal ketergantungan tersebut dalam kasus seperti ini:

1. Paket saya bergantung pada paket ini, tetapi saya berharap proyek target menyertakannya karena paket saya hanyalah sebuah plugin untuk paket itu: Taruh di peerDependencies .
2. Saya memiliki tes yang bergantung pada paket ini tetapi tidak terdaftar di dependencies (dan seharusnya tidak terdaftar di sana) untuk alasan apa pun: Taruh di devDependencies .

Dengan kata lain: Semua paket yang diharapkan ada selama pengembangan dan tidak terdaftar sebagai dependensi langsung dari paket yang sedang dikembangkan harus berada dalam devDependencies . Duplikat tidak menjadi masalah - tidak ada di dokumen yang menyatakan bahwa duplikat tidak diperbolehkan / didorong dalam kasus ini.

@nikolakanacki Ketika kita membangun sebuah plugin untuk sebuah paket, kita harus bergantung pada versi paket yang diinstal oleh pengguna, jika kita menambahkannya sebagai devDependency , kita pasti akan menginstal versi yang berbeda dan itu akan digunakan sebagai pengganti versi pengguna.

Kecuali kita mendefinisikan ketergantungan sebagai * , tetapi Yarn harus menjadi deterministik dan lebih memilih paket yang diinstal pengguna daripada milik kita.

Saat ini tidak demikian:

• https://github.com/yarnpkg/yarn/issues/3793
• https://github.com/yarnpkg/yarn/issues/3778

@alexilyaev Menurut saya @nikolakanacki berarti menginstal baik sebagai peerDependency dan devDependency.

Ini memiliki masalah yang harus kita jaga agar keduanya tetap sinkron. Bagi saya ini berfungsi dengan baik untuk saat ini tetapi menurut saya itu tidak ideal.

@alexilyaev saat Anda mendeklarasikan peerDependency Anda juga mendeklarasikan versinya. Kecuali proyek target memiliki versi dependensi peer yang diinstal yang juga memenuhi versi yang Anda tetapkan - yarn / npm akan melaporkan kesalahan (ketergantungan peer hilang, sesuatu seperti itu).

Bukan yang kurang devDependency tidak ada hubungannya dengan itu, itu adalah yang diinstal ketika menjalankan yarn atau npm install di dalam paket sumber (yang mendeklarasikan ketergantungan peer, mis. : a plugin), dan bahkan tidak dikonsultasikan ketika paket sedang digunakan oleh paket / proyek pihak ketiga (rekan).

Intinya adalah: Saya tidak melihat bagaimana semua ini relevan?

Saya dapat melihat sakitnya menyinkronkan mereka, tetapi Anda dapat dengan mudah menulis skrip bash / javascript / <whatever> yang akan memeriksa ini sebagai langkah pasca-pemasangan di package.json .

Hal yang ingin saya sampaikan adalah bahwa kita tidak boleh merusak sentimen devDependencies , atau lebih buruk lagi memperkenalkan "menjalankan yarn atau npm install tidak harus menginstal semua dependensi yang diperlukan dari konsep paket ini.

Di sisi lain yarn memperkenalkan kebijakan yang bahkan lebih ketat dalam hal ini, ia membersihkan paket yang tidak didefinisikan sebagai dependencies atau devDependencies sehingga Anda tidak menjalankan menjadi masalah nanti.

@nikolakanacki Katakanlah plugin saya menerima ^7.0.0 dan yang terbaru adalah 7.9.0 dan pengguna menetapkan package.json 7.4.0 .
jika saya akan memiliki ^7.0.0 dalam devDependencies juga, bukankah Yarn akan menginstal (untuk pengguna) 7.9.0 dan 7.4.0 ?

Jika ya, plugin saya mungkin keliru menggunakan 7.9.0 diinstal, bukan 7.4.0 .

@alexilyaev Paket Anda akan selalu, seperti paket lainnya dalam kasus lain, menggunakan versi tertinggi yang tersedia yang memenuhi "rentang semver" yang ditentukan dalam paket Anda untuk dep peer ini.

Saya akan lebih spesifik tetapi saya tidak begitu memahami kasus yang Anda ajukan, dapatkah Anda menjelaskan?

~ Ini akan memperingatkan Anda bahwa Anda memiliki ketidakcocokan peerDependency , plugin Anda mengharapkan ^7.0.0 dan Anda memiliki versi 7.4.0 . ~ Diperbarui: ^7.0.0 memenuhi 7.4.0 .

bukankah Yarn akan menginstal (untuk pengguna) 7.9.0 dan 7.4.0?

Yarn tidak menginstal peerDependencies untuk Anda dan tidak akan menginstal devDependencies plugin Anda hanya ketergantungan di dependencies .

@gaastonsr Anda benar sekali kecuali bahwa ^7.0.0 dipenuhi oleh 7.4.0 .

Dependensi peer tidak pernah diinstal, dependensi dev tidak diinstal secara default jika paket tersebut bukan paket utama. "Pengguna akhir" perlu menentukan dependensi peer mana yang ingin dipenuhi dengan menambahkannya ke "dependensi" reguler proyek, bersama dengan rentangnya. Ini bisa memenuhi atau tidak memenuhi "rentang semver" yang Anda butuhkan di plugin Anda, dan pengguna akan diberitahu tentang yang terakhir.

Rentang Semver dijelaskan oleh npm: https://docs.npmjs.com/misc/semver
Jika ragu, selalu periksa: http://jubianchi.github.io/semver-check/

@nikolakanacki untuk dapat dengan mudah menginstal paket ketergantungan akan sangat bagus!

@nikolakanacki Ok, jadi memang ketika pengguna akhir menginstal paket, devDependencies tidak terinstal, jadi pembuat paket harus menambahkan peerDependencies ke devDependencies juga.

Jadi, ini menyelesaikan masalah pembangunan lokal.

Namun, tampaknya banyak project yang tidak menambahkan dependensi peer sebagai dependensi dev.
Jadi saya rasa kita harus mulai menyebarkan berita dan menjalankan proyek.
Ini pasti akan mengarah pada diskusi panjang tentang mengapa itu berhasil dengan npm tetapi tidak dengan Yarn, dan terlepas dari hasilnya, itu akan memakan waktu cukup lama dan tidak semua proyek dapat melakukan perubahan.

Jadi ... Saya mengusulkan untuk tetap mendukung cara menginstal dependensi peer, setidaknya agar kita tidak perlu menggunakan install-peerdeps lagi.

Apa masalah sebenarnya di sini? Tampaknya menginstal satu daftar deps akan lebih rumit daripada memasang daftar deps yang lain. Ketergantungan sesama telah ada selama beberapa tahun. Bagaimana ini tidak mengganggu siapa pun?

Solusi @nikolakanacki masuk akal. Itu yang kami gunakan untuk pengembangan perpustakaan kami. Anda memerlukan devDependencies penyiapan dengan benar di perpustakaan untuk pengujian terisolasi (di luar proyek host yang memasok peerDependencies ) dan Anda memerlukan peerDependencies untuk pengujian terintegrasi dan untuk memastikan host proyek tidak berakhir dengan penginstalan paket yang berlebihan / duplikat karena pustaka yang dipakai menggunakan dependencies dan _ tidak _ menggunakan peerDependencies dan devDependencies .

Ada sedikit sakit kepala karena menjaga mereka tetap sinkron. Namun seperti yang ditunjukkan oleh @nikolakanacki, hal ini dapat dengan mudah dikurangi melalui skrip post-install .

Solusi apa?

Saya telah menjalankan komentar dengan cukup cepat dan tidak melihat solusi sederhana:

Harap selalu instal peerDependencies sebagai dependensi biasa, jika itu ada dalam paket level teratas

Ini sangat cocok dengan kasus pengembangan / uji dan tidak mempengaruhi instalasi paket sebagai ketergantungan. Mirip dengan logika yang kita miliki untuk yarn.lock. Tidak perlu "pengembangan" ekstra atau mode apa pun.

Sebenarnya, karena bug benang lain yang terkait dengan peerDependencies, tampaknya persis bagaimana perilakunya dalam beberapa kasus.

Sangat setuju, jika Anda menjalankan 'yarn install' di repo, itu harus menginstal dependensi peer yang belum terdaftar di deps. Saya tidak benar-benar melihat perbedaannya dengan dependensi dev dalam hal itu— jika Anda mengembangkan modul itu, Anda _membutuhkan_ modul ini untuk diinstal

Saya menutup ini karena saya tidak bisa mendapatkan gambaran yang jelas tentang apa masalahnya dan apa solusi yang diusulkan jika ada.

Jangan ragu untuk membuka kembali dengan klarifikasi atau melaporkan bug baru.

@BYK apakah Anda benar-benar yakin melakukan hal yang benar untuk menutup masalah dengan 55 jempol dan 34 komentar hanya karena tidak jelas bagi Anda?

Menurut saya, ini cukup mudah: pastikan peerDependencies diinstal saat disetel dalam paket tingkat atas .
Atau katakanlah dengan cara lain: perlakukan peerDependencies sebagai dependensi reguler saat disetel dalam paket saat ini

Menambahkan dependensi peer juga sebagai dependensi dev, seperti yang diusulkan lebih lanjut di utas ini, akan merusak jenis aliran: https://github.com/flowtype/flow-typed/issues/379

@andvgal Saya hanya mencoba membereskan masalah dan semua diskusi di sini dari beberapa bulan yang lalu sangat luar biasa dan sulit untuk diringkas.

Menurut saya, ini cukup mudah: pastikan peerDependencies diinstal saat disetel dalam paket tingkat atas.
Atau katakanlah dengan cara lain: perlakukan peerDependencies sebagai dependensi reguler saat disetel dalam paket saat ini

Ini adalah ringkasan yang bagus, terima kasih. Membuka kembali masalah, tetapi kami perlu memikirkan dengan sangat hati-hati tentang implikasi penginstalan peerDependencies secara default jika kami memutuskan untuk melakukannya.

Atau - setidaknya - berikan cara untuk menginstal dependensi peer secara terpisah tanpa menyentuh file package.json. Saat menggunakan add untuk menginstal dependensi peer, entri di file JSON diubah. Jika Anda telah mengatur ekspresi semver Anda dengan cara yang berbeda dari yang ditulis oleh benang secara default, itu akan berubah.

Saya rasa ide untuk menambahkan --peer switch untuk menginstal tidak apa-apa, tetapi saya sebenarnya ingin menginstalnya satu per satu, karena saya sering menautkan beberapa modul ini, dan saya bolak-balik antara tautan dan sebenarnya memasang modul. Dengan npm, saya hanya bisa menjalankan 'npm i'. Di Yarn, saya tidak melihat padanannya. Secara khusus, saya ingin dapat menginstal satu file, menggunakan spesifikasi di package.json, tanpa mengubah file package.json.

@jimsugg , saya telah menggunakan yarn add <package...> -p , untuk menginstal dependensi peer secara manual yang sudah terdaftar di package.json, yang jelas merupakan anti-pola. Sepertinya dependensi peer harus diinstal secara otomatis di lingkungan pengembangan (jika sebenarnya dependensi peer, setidaknya harus ada pengujian yang memerlukan paket tersebut).

Saya mencari hal yang sama dan menemukan Bash one-liner ini untuk menginstal semua deps peer yang terdaftar (mengharuskan Anda untuk menginstal jq): yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json) .

Saya harap ini membantu orang lain.

@EdwardDrapkin Terima kasih untuk itu, ide legendaris! Saya memperpanjangnya dan akhirnya menambahkan skrip npm untuk melakukan ini:

"install:peers": "yarn add -P $(jq -r '.peerDependencies | to_entries | map(\"\\(.key)@\\(.value | tostring)\") | join(\" \")' package.json)",

Pertahankan saja spesifikasi versi dari peerDependencies juga;) Hanya halangan di sini setelahnya adalah jika Anda tidak ingin menggunakan tag latest , melainkan tag lain yang sedang Anda kerjakan seperti next atau sesuatu.

@shousper berikut adalah cara tanpa ketergantungan jq :

node -e "const peers = Object.entries(require('./package.json').peerDependencies || {}).map(d => d.join('@')).join(' '); if (peers.length) process.stdout.write('yarn add -P --no-lockfile ' + String(peers));" | sh

Adakah skenario di mana Anda tidak ingin menginstal dependensi peer paket Foo saat Anda bekerja langsung pada Foo ? Saya tidak bisa memikirkan satu pun. Jika Bar diperlukan untuk menggunakan Foo , Anda memerlukannya saat mengerjakan Foo , dan karena ini adalah ketergantungan rekan, itu tidak bisa menjadi ketergantungan biasa. Itu kemudian harus diinstal hanya ketika bekerja secara langsung pada paket, yang dilakukan oleh dependensi dev.

Karena itu, menurut saya masuk akal bagi benang untuk memperlakukan peerDependencies sama seperti devDependencies tetapi kemudian juga melakukan apa yang mereka lakukan sekarang, yang menghasilkan peringatan. Saya biasanya hanya membuat setiap ketergantungan sesama menjadi ketergantungan, jadi ini akan menghemat beberapa duplikasi.

Apakah ada alasan melakukan itu akan menjadi masalah? Ini mungkin akan menjadi perubahan besar sehingga harus menunggu hingga 2.0, tapi selain itu sepertinya akan baik-baik saja.

Satu masalah mungkin Anda menginginkan versi yang lebih spesifik dipasang untuk dev daripada persyaratan rekan Anda. Dalam hal ini, saya akan mengatakan bahwa Anda harus dapat mengganti versi peer untuk instalasi lokal dengan menduplikasinya di devDependencies. Sebagai contoh

peerDepdency: react@^16.0.0
devDependency: react@~16.1.0

Akan membatasi penginstalan lokal react ke ~ 16.1.0, tetapi mengizinkan versi v16 apa pun sebagai dependensi peer. Saya tidak sepenuhnya yakin di mana hal seperti itu akan diperlukan, tetapi tampaknya tidak valid.

Saya setuju @bdwain , saya memahami secara semantik apa perbedaan antara ketergantungan peer dan dev, tetapi dalam praktiknya mereka dipasang dengan cara yang persis sama; jika Anda sedang mengembangkan modul, Anda perlu menginstal dependensi dev dan peer, dan jika Anda menggunakan modul, Anda hanya menginstal dependensi sebenarnya yang terdaftar. Jika demikian, saya tidak melihat alasan yang sangat bagus untuk tidak memiliki dependensi dev dan peer yang berperilaku berbeda dalam perintah install

@bdwain @kyleholzinger Saya tidak setuju, karena peerDependencies benar-benar dimaksudkan untuk menginformasikan perlunya ketergantungan, bukan untuk menginstruksikan tindakan aktual penginstalan ketergantungan.

Ini memastikan bahwa masalah versi dependensi sementara yang juga ada di paket root / level atas tidak digunakan secara diam-diam (dan salah). Pertimbangkan babel-core sebagai contoh.

Kurangnya dukungan di sini dalam konteks benang adalah kemampuan untuk mendefinisikan baik sebagai peer maupun dev dep, seperti yang dijelaskan di sini .

Yang mengatakan, untuk tetap sejalan dengan spesifikasi instal default untuk deps peer dan untuk memberikan pengalaman dev yang lebih baik .... mungkin yarn bisa memperkenalkan opsi --include-peers untuk perintah install?

@hulkish Meskipun saya setuju dengan sentimen tersebut, kapan akan menjadi contoh ketika Anda ingin mendeklarasikan sesuatu sebagai ketergantungan sesama, tetapi _not_ sebagai ketergantungan dev?

Jika saya memahami penggunaannya dengan benar, terutama dengan benang, daftar dependensi peer selalu merupakan bagian dari dependensi dev. Jika ini masalahnya, saya rasa ini harus diakui secara resmi dan Anda tidak perlu mendeklarasikan dependensi peer sebagai dependensi dev.

Satu-satunya alasan saya mengemukakannya adalah ketika saya berpikir menambahkan perintah / opsi yang akan menambahkan sesuatu karena ketergantungan dev dan peer terasa seperti itu akan meningkatkan kompleksitas benang secara umum, dan saya merasa ada solusi di suatu tempat di sini yang bagus dan sederhana 😄

@tokopedia

@hulkish Meskipun saya setuju dengan sentimen tersebut, kapan akan menjadi contoh ketika Anda ingin menyatakan sesuatu sebagai ketergantungan sebaya, tetapi bukan sebagai ketergantungan dev?

Saat Anda tidak membutuhkannya untuk pengujian unit atau.build untuk dijalankan. Menurut pengalaman saya, ini sebenarnya satu-satunya kebutuhan untuk menambahkan keduanya di kedua tempat, untuk memulai.

Saya pikir solusinya di sini adalah agar benang memperkenalkan opsi yang memungkinkan pemasangan otomatis rekan. Perlu diketahui bahwa manfaat utama menggunakan peerDependencies adalah untuk mendapatkan visi tentang kapan dependensi transien yang tidak kompatibel digunakan. Kuncinya di sini adalah untuk tidak merusak perilaku default bergantung pada pemasangan.

Saya pikir @hulkish sedang berbicara tentang skenario di mana Anda mengandalkan ketergantungan pada ketergantungan untuk menarik salah satu ketergantungan sebaya Anda. Namun, menurut saya hal ini tidak akan menimbulkan masalah karena ketergantungan transitif masih harus cocok dengan kisaran yang ditentukan oleh ketergantungan rekan, yang bagaimanapun juga harus dalam kisaran besar. Jika ketergantungan transitif lebih spesifik daripada ketergantungan rekan, kisaran itu akan diutamakan dan semua persyaratan akan tetap terpenuhi.

@rumahguguk

Saat Anda tidak membutuhkannya untuk pengujian unit atau.build untuk dijalankan

Benar-benar mengerti! Meskipun itu menimbulkan pertanyaan: jika sesuatu adalah dependensi peer, tetapi Anda tidak membutuhkannya untuk pengujian unit atau build Anda untuk berjalan, lalu mengapa Anda memilikinya sebagai dependensi peer?

Perlu diketahui bahwa manfaat utama menggunakan peerDependencies adalah untuk mendapatkan visi tentang kapan dependensi transien yang tidak kompatibel digunakan

Ini saya sangat setuju dengan, saya pikir dependensi peer sekarang luar biasa dari konsumen modul yang menyatakan ketergantungan pada perpustakaan dengan dependensi peer, keluhan / rasa sakit utama saya adalah ketika mengembangkan modul yang memiliki dependensi peer. Maaf jika ada kebingungan!

Permintaan / saran utama saya / harapan-untuk-mendapatkannya-disetujui-untuk-kerja adalah ketika Anda yarn install (tidak dalam produksi) dalam modul yang memiliki dependensi peer sendiri package.json baik dependensi devnya _serta_ dependensi peer-nya diinstal. Itulah perbedaan utamanya, saat ini hanya dependensi dev yang diinstal, jadi Anda harus mendeklarasikan deps sebagai dependensi dev dan dependensi peer.

@bdwain @hulkish

Saya pikir @hulkish sedang berbicara tentang skenario di mana Anda mengandalkan ketergantungan pada ketergantungan untuk menarik salah satu ketergantungan sebaya Anda

Saya secara khusus berbicara tentang ketika Anda melakukan yarn install saat mengembangkan modul dengan dependensi peer, bukan ketika Anda menambahkan modul dengan dependensi peer ke proyek lain

@bdwain tidak persis, itu pasti hal yang licin untuk dijelaskan. Saya akan mencoba menggunakan contoh:

Gunakan kasus dengan masalah

Katakanlah ini adalah paket level teratas Anda:

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

lalu, foo / package.json Anda:

  "dependencies": {
    "react": "^16.0.0"
  }

Berdasarkan pohon ketergantungan ini, ketika Anda menjalankan instalasi yarn / npm, direktori node_modules Anda akan terlihat seperti ini:

node_modules/
  react/ <-- @^15.0.0
  foo/node_modules/react/ <-- @^16.0.0

Pada titik ini, kecuali jika Anda (untuk alasan apa pun) memutuskan untuk secara sukarela memeriksa struktur node_modules bersarang Anda - Anda tidak akan pernah tahu ada masalah. Ini bukan kesalahan manajer paket - ia menyelesaikan tugasnya dengan akurat.

Jadi, peerDependencies dimaksudkan untuk menyelesaikan kasus penggunaan ini dengan memperlakukannya lebih sebagai pemeriksaan validasi daripada instruksi untuk menginstal.

Gunakan kasus dengan solusi peerDependencies

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

lalu, foo / package.json Anda:

  "peetDependencies": {
    "react": "^16.0.0"
  }

Pertama, mari kita perjelas bahwa pada titik ini kedua kasus penggunaan memiliki masalah yang sama yaitu versi react tidak kompatibel satu sama lain.

Perbedaan dalam use case ini adalah; Alih-alih masalah ini diam-diam ada. Ketika Anda menjalankan npm / yarn install - manajer paket memiliki tugas untuk melaporkan ketidakcocokan sebagai kesalahan atau peringatan.

Semoga ini menjelaskannya lebih baik.

@tokopedia

Saya secara khusus berbicara tentang kapan Anda melakukan pemasangan benang saat mengembangkan modul dengan dependensi peer, bukan ketika Anda menambahkan modul dengan dependensi peer ke proyek lain

Saya mengerti. Saya pikir perilaku default untuk peer deps harus tetap apa adanya. Tapi, saya pikir solusi yang mudah adalah membiarkan ini dikonfigurasi melalui cli dan / atau env vars dan / atau .yarnrc . Sesuatu seperti --install-peers-as-dev

@rumahguguk

Tapi, saya pikir solusi yang mudah adalah dengan memungkinkan ini dikonfigurasi melalui cli dan / atau env vars dan / atau .yarnrc. Sesuatu seperti --install-peers-as-dev

Yeah! Menurut saya pribadi, mereka seharusnya tidak berada dalam dependensi dev dan dependensi peer, tetapi itu bisa menjadi diskusi terpisah. Saya pikir menambahkan opsi ini akan menjadi kompromi yang solid dan cara yang bagus untuk menyelesaikan masalah sementara itu-- Saya akan memeriksanya dan mencoba menggabungkan sesuatu :)

@kyleholzinger ini adalah tempat yang baik untuk memulai https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58

Juga, saya mendorong dalam pr Anda bahwa saat meneruskan peerDependencies untuk diinstal sebagai dev - Anda ingin memastikan peringatan kompatibilitas atau kesalahan masih dilaporkan.

@hulkish Saya mengerti apa itu dependensi peer. Maksud saya adalah bahwa dalam praktiknya, Anda selalu membutuhkannya diinstal untuk tujuan pengembangan, jadi mereka harus diperlakukan sebagai devDependencies selain peran mereka dalam memberikan peringatan ketika versi tidak cocok.

Jika sebuah paket Foo memiliki ketergantungan rekan di Bar, satu-satunya skenario di mana Anda tidak ingin Bar diinstal saat bekerja langsung di Foo adalah jika pengujian build dan otomatis Anda tidak memerlukan Bar. Tetapi jika itu masalahnya, itu berarti build / tes Anda tidak menjalankan fungsionalitas yang membutuhkan ketergantungan peer pada Bar di tempat pertama, yang seharusnya bukan kasus umum.

Saya tidak benar-benar berpikir opsi untuk mengaktifkan pemasangan otomatis dependensi peer adalah hal yang tepat untuk dilakukan karena itu akan lebih sering dibutuhkan daripada tidak (kecuali Anda juga menentukan peer sebagai dependensi dev, yang mengalahkan intinya). Jika sebuah opsi lebih sering dibutuhkan daripada tidak, itu harus menjadi default dan sebagai gantinya harus ada opsi untuk menonaktifkannya. yarn install seharusnya berfungsi tanpa opsi untuk kasus yang paling umum, dan memerlukan dependensi peer untuk diperlakukan sebagai dependensi dev adalah kasus yang paling umum. Menambahkan langkah ekstra untuk rata-rata pengguna hanyalah pengalaman yang lebih buruk.

Dan menambahkannya secara otomatis ke dev dan peer masih memiliki masalah dalam menduplikasi dependensi di dua tempat, yang mana IMO merupakan masalah dan seharusnya tidak diperlukan.

Apa pun itu, peringatan / kesalahan tersebut perlu dilaporkan.

Bagaimana mungkin kami belum memiliki fitur ini? Saya baru dalam membuat paket npm, tetapi sepertinya ini adalah bagian dari alur kerja inti pengembangan paket npm.

@Biels yang sama! Saya benar-benar lupa saya mengatakan saya akan mengerjakan ini jadi belum mulai, saya akan mencoba mengerjakannya ketika saya bisa jadi setidaknya kita bisa meminta orang meletakkan opsi ini di .yarnrc dan tidak perlu khawatir tentang itu sepanjang waktu

Menurut saya fitur ini sangat penting.

Saya dapat memikirkan banyak kasus penggunaan, terutama jika berkaitan dengan penulis perpustakaan.

Katakanlah saya ingin mengembangkan pustaka komponen yang memiliki react dan react-dom sebagai peerDependencies (Saya tidak ingin mereka akhirnya digabungkan oleh siapa pun yang menggunakannya, itu akan menduplikasi kedua perpustakaan itu dan dapat menyebabkan masalah, yang pernah saya alami sebelumnya).

Saya ingin menguji pustaka komponen saya dengan peerDependencies terpasang, jadi saya ingin menjalankan yarn --include-peerDeps (atau semacamnya) di CI dan mesin saya, tetapi ketika seseorang menjalankan yarn pada paket mereka sendiri Saya ingin mereka menggunakan dependensi react dan react-dom mereka sendiri untuk menjalankan pengujian mereka (tidak peduli bagaimana mereka melakukannya).

Saya juga berpikir bahwa karena kami memiliki modul di luar sana yang melakukan hal ini dan memiliki banyak unduhan, itu sudah membenarkan membuat fitur ini asli. (Motto lama "buat sesuatu yang diinginkan orang" berlaku di sini IMO)

Saya tidak dapat melihat bagaimana ini bisa menjadi praktik yang buruk karena harus secara eksplisit diubah melalui --include-peerDeps .

Saya senang berdiskusi dan membantu penerapannya jika diperlukan.

@lucasfcosta sangat setuju! Saya tidak punya banyak waktu untuk mengerjakannya akhir-akhir ini jadi telah mencoba mencari-cari ketika saya bisa, tetapi sepertinya tidak bisa mendapatkan opsi yang sebenarnya dari opsi baris perintah. Akan sangat senang dengan uluran tangan :)

@lucasfcosta inilah implementasi buruk saya di mana saya pikir opsi mungkin hidup, saya tidak tahu. Mencoba mengikuti pola dari beberapa opsi baris perintah lainnya, tetapi tampaknya tidak berhasil.

Saat ini saya menggunakan pendekatan duplikasi (devDependencies dan peerDependencies) tetapi akan sangat menyukai fitur ini sehingga saya dapat berhenti melakukannya.

Saya butuh itu juga. Sementara itu saya telah melakukan tugas simpul kecil

const pkg = require('./package.json');
const entries = Object.entries(pkg.peerDependencies);
const shell = require('shelljs');

let deps = ['yarn add'];
for ([dep, version] of entries) {
    deps[deps.length] = `${dep}@${version}`;
}

deps.push('--peer');
const cmd = deps.join(' ');
console.log('Installing peer deps!\n -----', cmd);
const result = shell.exec(cmd);

if (result.code !== 0) {
    shell.echo('Error: installing peer dependencies');
    shell.exit(1);
}

Keren! Sekarang kita bisa menempelkannya menjadi benang dan menambahkan bendera atau apapun.

Pada Kamis, 4 Okt 2018, 17:29 Pasquale Mangialavori [email protected]
menulis:

Saya butuh itu juga. Sementara itu saya telah melakukan tugas simpul kecil

`const pkg = membutuhkan ('./ package.json');
const entries = Object.entries (pkg.peerDependencies);
const shell = membutuhkan ('shelljs');

biarkan deps = ['benang tambahkan'];
untuk ([dep, versi] entri) {
deps [deps.length] = $ {dep} @ $ {version};
}

deps.push ('- peer');
const cmd = deps.join ('');
console.log ('Menginstal peer deps! n -----', cmd);
hasil const = shell.exec (cmd);

if (result.code! == 0) {
shell.echo ('Kesalahan: menginstal dependensi peer');
shell.exit (1);
} `

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/1503#issuecomment-427063046 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AE64MGxna2iQ-BFNiC52mIVro8sydPu1ks5uhilsgaJpZM4KiMuo
.

Saya juga menggunakan pendekatan duplikasi seperti yang dikatakan @RWOverdijk . Senang melihat fitur ini di masa mendatang.

Btw, apakah ada yang punya solusi yang lebih baik sehingga kita tidak perlu menambahkan satu paket dua kali (devDependencies dan peerDependencies)?

Halo dari masa depan. Ini masih menjadi masalah bagi pengembang paket / lib. Deps duplikat seharusnya tidak menjadi jawaban.

Saya pasti ingin melihat fitur ini ditambahkan. Tanpa menambahkan react ke paket saya devDependencies , saya tidak dapat menjalankan tes pada kode saya.

Sebuah flag untuk menginstal paket-paket di objek peerDependencies akan bagus tetapi saya juga tidak melihat _any_ downside untuk membuat instalasi _only_ local peerDependencies sebagai perilaku default. Dan secara semantik masuk akal, dependensi peer harus ada di sana agar paket dapat bekerja di tempat lain, mengapa itu berbeda secara lokal?

Pendapat saya tentang penggunaan bendera adalah sebagai berikut karena keselarasannya dengan
yarn add --peer perintah.

yarn --peer
# and
yarn install --peer

Setidaknya bendera harus dikenalkan.

Saya ingin tahu apakah menggunakan aplikasi test adalah solusi yang baik di sini? Anda kemudian dapat menambahkan semua peerDependencies sebagai dependencies dari aplikasi test . Ini sepertinya melakukan hal berikut:

• menyimpan peerDependencies dari devDependencies di perpustakaan Anda
• Anda akan menguji pustaka Anda, dengan cara ... memastikan bahwa dist Anda dibangun dengan benar, Anda mengekspor semua komponen dengan benar dan hal semacam itu
• hindari kesalahan Invalid hook call sesekali ketika Anda lupa menghapus node_modules dari paket Anda saat menggunakan dependensi lokal, seperti "my-package": "file:/path/to/my-package"

Jika info lebih lanjut akan bermanfaat bagi orang-orang, saya membuat repo demo dalam upaya untuk memodelkan pendekatan ini dan mendokumentasikan masalah:
https://github.com/jamstooks/package-peer-dependencies

Untuk saat ini, Anda seharusnya dapat menjalankan npx install-peerdeps <package> dan CLI akan menanyakan apakah Anda ingin menggunakan Yarn untuk menginstal, jika Anda memiliki kunci benang dll di folder. Setidaknya itu berhasil untuk saya sekarang.

Diskusi lebih lanjut dari Arcanis ("gagal menginstal pada deps peer yang hilang") dan Isaac ("instal peer deps secara otomatis") di sini di NPM RFC ini:

https://github.com/npm/rfcs/pull/43

Entri blog ini membantu saya mengatasi masalah ini: https://dev.to/yvonnickfrin/how-to-handle-peer-dependencies-when-developing-modules-18fa

Sepertinya saya memiliki masalah terkait.
Untuk repro minimal saya memiliki daftar dependensi ini:

  "dependencies": {
    "prismic-reactjs": "^1.2.0"
  },
  "peerDependencies": {
    "react": "^16.12.0"
  },
  "devDependencies": {
    "react": "^16.12.0",
    "redux": "^4.0.5"
  }

Penjelasan: paket saya bergantung pada kehadiran react saat runtime dan juga membutuhkannya untuk pengujian. redux ada di sini untuk tujuan demo, lihat di bawah.

Sekarang, prismic-reactjs juga bergantung pada react sebagai ketergantungan rekannya.
Apa yang terjadi setelah yarn --production dipanggil?

React adalah _installed_ dan _hoisted_
Saya berharap _tidak ada_ dari keduanya terjadi.

Untuk tujuan demo redux ditambahkan di sini yang _not_ diinstal yang (menurut saya) membuktikan ketergantungan rekan sementara adalah penyebab masalah.

Repro repo: https://github.com/emirotin/yarn-react-repro . Jalankan test.sh untuk pemeriksaan cepat.

npm memiliki fitur ini sekarang dengan v7 ... ada alasan untuk tidak menambahkan ini ke thread?

@sajadghawami sejauh yang saya tahu, @arcanis memiliki beberapa keberatan yang cukup besar untuk melakukan ini:

https://github.com/npm/rfcs/pull/43#issuecomment -520584797