Yarn: Jangan peringatkan tentang dependensi opsional yang tidak kompatibel

Sepertinya penggunaan peringatan yang tepat bagi saya.

Bukankah lebih baik memperbaiki hal yang memberi peringatan daripada hanya menyembunyikannya?

@tokopedia

Apa yang Anda maksud dengan "memperbaiki"? Seperti yang dijelaskan di https://github.com/npm/npm/issues/11632 , semuanya berfungsi sebagaimana mestinya. Beberapa paket bergantung pada fsevents khusus pada macOS (karena menawarkan pengalaman yang lebih baik) tetapi kembali ke perilaku lain di Windows / Linux. Fakta bahwa fsevents tidak kompatibel dengan Windows seharusnya tidak diungkapkan kepada pengguna: ini hanya detail implementasi khusus platform dari suatu ketergantungan. Tidak ada yang dapat ditindaklanjuti untuk pengguna di sana (dan tidak ada yang perlu dikhawatirkan).

Saya akan mengatakan bahwa membutuhkan ketergantungan dan menambahkan binari untuk OS tertentu seharusnya tidak bagaimana cara kerjanya.
Saya yakin ada paket lain yang membuat masalah ini muncul, tetapi fsevents adalah yang paling dominan, mendapatkan masalah di babel , webpack , create-react-app , dan saya yakin segera sane dan jest . Saya pikir akan lebih produktif untuk menemukan solusi menonton file yang lebih baik daripada mengubah perilaku manajer paket karena kekurangan satu paket.

Jika Anda memiliki saran alternatif tentang paket apa yang dapat dilakukan dengan fsevents (atau fsevents itu sendiri), saya ingin mendengarnya! Saya tidak berpikir ada yang "salah" tentang memiliki paket yang khusus OS. Ini memecahkan masalah nyata, dan beberapa masalah khusus untuk platform.

Sepertinya ada perbedaan pendapat.
Saya kira peringatan tentang hal yang tidak dapat ditindaklanjuti bisa mengganggu.
Di sisi lain, peringatan serupa, misalnya "modul ini tidak berfungsi di Node.js <4", cukup berguna.
Apakah ada pengaturan yang dapat diaktifkan untuk menonaktifkan peringatan?

@gaearon diberikan ini adalah repo open source, bagaimana jika PR menambahkan bendera CLI untuk menekan tingkat log. Akan sangat tidak tepat untuk membahas masalah hilir dalam paket yang Anda referensikan apakah itu komputer superior atau hanya RPi $ 35 yang dapat melakukan sebagian besar hal yang sama.

@bayu_joo

bagaimana dengan PR untuk menambahkan bendera CLI untuk disembunyikan oleh tingkat log

Saya ingin sekali mengirim PR tetapi, seperti @bestander , saya juga bekerja penuh waktu untuk memelihara proyek sumber terbuka lainnya, dan sayangnya tidak punya waktu untuk mengerjakan fitur khusus ini. Saya mengangkat masalah untuk membahas apakah itu diinginkan atau tidak.

Akan sangat tidak tepat untuk membahas masalah hilir dalam paket yang Anda referensikan apakah itu komputer superior atau hanya RPi $ 35 yang dapat melakukan sebagian besar hal yang sama.

Saya tidak mengerti komentar ini. Saya tidak menyarankan untuk "menutupi masalah hilir". fsevents tidak melakukan kesalahan apa pun. Ia ingin menyatakan bahwa ini hanya berguna di macOS, tetapi tidak ada di sistem lain. Paket lain, seperti webpack , ingin menyatakan bahwa mereka ingin menggunakan fsevents di macOS, tetapi ingin melewatinya di sistem lain. Dan inilah yang dilakukan oleh benang dan npm.

Semuanya sudah berfungsi sebagaimana mestinya, kecuali bahwa npm dan benang juga mencetak pesan yang terlihat menakutkan tetapi sebenarnya tidak menunjukkan masalah . Tetapi tidak ada alasan bagi pengguna untuk khawatir karena semuanya berfungsi sebagaimana mestinya. Jadi maksud saya adalah sebaiknya berhenti menakut-nakuti pengguna saat tidak ada yang salah.

Maaf jika saya tidak terlalu jelas. Saya bisa melihat sekarang ini lebih kontroversial dari yang saya harapkan. Jangan lakukan ini. Aku tidak akan mati di bukit ini. 😛

Di sisi lain, peringatan serupa, misalnya "modul ini tidak berfungsi di Node.js <4", cukup berguna.

... tapi itu bisa ditindaklanjuti - Anda bisa meningkatkan versi Node.js.

... tapi itu bisa ditindaklanjuti - Anda bisa meningkatkan versi Node.js.

Batasan OS juga bisa ditindaklanjuti.
Saya kira pertanyaannya adalah apakah perlu menampilkan peringatan yang sama setiap kali Anda menginstal alat IO bukan di Mac, saya pikir kita harus memberi pengguna windows kesempatan untuk tidak menampilkannya ketika dependensi bersifat opsional.

Saya akan buka kembali, sepertinya perlu dibahas lebih banyak.

Kami mungkin dapat menurunkan ini ke tingkat log "info" (dan memperkenalkan konsep tingkat log seperti yang dimiliki npm).

@gearon Bisakah Anda memberikan dua kasus uji gratis? Saya membaca detailnya dan mendengar saran itu. Tapi secara pribadi saya ingin menganggap apa yang Anda anggap sebagai pengalaman menakutkan bagi pemula untuk sesuatu yang "hampir tidak pernah bisa ditindaklanjuti". Anda menyebutkan Webpack di atas. Bagi saya Webpack sendiri menakutkan dan akibatnya saya tidak menggunakannya. Ada banyak hal hebat yang dapat dilakukan dengan benang jika terus memperhatikan set fitur yang tepat selama pengembangan. Apakah ini benar-benar saran yang menurut Anda membantu mencapai tujuan tersebut, atau apakah Anda mendaki bukit orang lain?

Saya mengalami situasi serupa seperti yang dijelaskan oleh @gaearon : Saya mendapatkan peringatan tentang dependensi yang menggunakan dependensi yang lebih lama dan saya kira mereka belum meningkatkannya?

Ketika saya menjalankan yarn upgrade saya mendapatkan ini di awal:

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

Tetapi ketika saya melihat daftar berikut, dependensi tersebut adalah yang terbaru.

Saya setuju dengan @gaearon , melihat peringatan agak menakutkan terutama bagi saya karena saya relatif baru menggunakan Node dan telah bermigrasi dari menggunakan npm ke Yarn. Tetapi juga agak _misleading_ untuk melihat pesan peringatan karena itu menyiratkan bahwa itu adalah sesuatu yang dapat saya perbaiki.

Menurut pendapat saya, menurut saya peringatan ini harus menjadi info yang ramah atau tidak ditampilkan sama sekali.

Namun, penggunaan dependensi yang tidak aman seharusnya memberikan peringatan.

Mengapa kita berbicara tentang _scary_. Ini adalah pengembangan perangkat lunak, bukan taman kanak-kanak.

@wtgtybhertgeghgtwtg Apa yang membuat saya marah adalah bahwa peringatan meminta _me_ untuk memperbarui sesuatu yang tidak dapat saya perbarui. Meskipun, dalam kasus ini, saya bukan orang yang menggunakan dependensi yang tidak aman (menurut saya Glob), saya mengerti maksud Anda dan setuju itu harus menjadi peringatan; tapi saya pikir itu bisa dikatakan lebih informatif. Sesuatu yang sederhana seperti "[dependency_A] is using an outdated [dependency_B]" - Saya akan langsung tahu bahwa a) ini bukan kesalahan _my_, kesalahan bukan pada pihak saya, dan b) ke mana harus pergi untuk melihat apakah masalah telah diatasi. Info semacam itu dapat menyelamatkan pengguna agar tidak jatuh ke lubang kelinci untuk mencoba mencari tahu apa yang salah di pihak mereka.

Ide bagus untuk memperbaiki pesan terlebih dahulu, kirim PR

Pada 7 Juli 2017 pukul 14:08, Daniel Blake [email protected] menulis:

@wtgtygtwtg https://gub.com/wtgtyhertgeghgtwtg
saya adalah bahwa peringatan tersebut meminta saya untuk memperbarui sesuatu yang tidak dapat saya perbarui.
Padahal, dalam kasus ini, saya bukan orang yang menggunakan unsafe dependency (I
pikir Glob adalah), saya mengerti maksud Anda dan setuju itu harus menjadi peringatan; tetapi saya
pikir itu bisa dikatakan lebih informatif. Sesuatu yang sederhana seperti
"[dependency_A] menggunakan [dependency_B] yang sudah ketinggalan zaman" - Saya akan langsung tahu
kelelawar yang a) itu bukan salah saya , kesalahan bukan di pihak saya, dan
b) ke mana harus pergi untuk melihat apakah masalah telah ditangani. Semacam itu
info dapat menyelamatkan pengguna dari lubang kelinci untuk mencoba mencari tahu
apa yang salah di pihak mereka.

-
Anda menerima ini karena Anda mengubah status buka / tutup.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/3738#issuecomment-313793331 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/ACBdWI1Ks6bSYH_BStzm_b3-ne3bUMT3ks5sLp5PgaJpZM4OGrsi
.

Apa yang membuat saya marah adalah bahwa peringatan tersebut meminta saya untuk memperbarui sesuatu yang tidak dapat saya perbarui.

Jika Anda menggunakan ketergantungan, Anda pasti memilikinya dan semua yang ditariknya, dan memiliki kemampuan untuk bercabang dan meningkatkan apa pun yang menyertainya. Jika itu mengganggu Anda, mungkin itu tidak layak digunakan.

Sementara saya akan membantahnya

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

memberi tahu Anda apa yang perlu Anda ketahui, saya setuju bahwa kata itu bisa disusun dengan kata-kata yang merangkumnya sedikit lebih baik.

Bisakah kita menjaga masalah ini tetap fokus pada satu kasus tertentu? Saya tidak ingin ini berubah menjadi bikeshed tentang semua kemungkinan peringatan.

Saya melaporkan peringatan khusus di mana "memperbaiki" masalah pada prinsipnya tidak mungkin, bahkan dalam dependensi transitif. Semuanya berfungsi sebagaimana mestinya.

Kasus lain yang dijelaskan dalam masalah ini menunjukkan masalah sah yang perlu dilaporkan dan diperbaiki oleh dependensi transitif. Menurut saya ini tidak mirip dengan masalah yang saya jelaskan. Jika Anda sangat menginginkannya, ajukan masalah baru.

Saya tidak ingin ini berubah menjadi bikeshed tentang semua kemungkinan peringatan.

Jika terkait, percakapan mungkin harus langsung ke sini. Harap perhatikan jumlah masalah terbuka, dan ini adalah permintaan peningkatan dan bukan bug.

Kedengarannya bagus. Saya akan berhenti berlangganan tetapi saya harap diskusi ini tetap fokus di masa mendatang. Terima kasih telah berpartisipasi!

Maintainers, tutup ini. Tidak ada yang bisa ditindaklanjuti.

Bisakah Anda memberikan dua kasus uji gratis?

Ada banyak hal hebat yang dapat dilakukan dengan benang jika terus memperhatikan set fitur yang tepat selama pengembangan.

Harap perhatikan jumlah masalah terbuka, dan ini adalah permintaan peningkatan dan bukan bug.

Maintainers, tutup ini.

@jhabdas , saya menghargai upaya Anda untuk membuat saya berkontribusi lebih banyak atas waktu saya untuk masalah ini, dan menunjukkan bahwa tim Yarn sudah cukup banyak, tetapi tidak perlu terus mengulangi hal ini. Ini bukanlah perilaku yang sangat bersahabat.

Saya minta maaf tapi seperti yang sudah saya katakan sebelumnya, saya tidak bisa benar-benar mendedikasikan waktu untuk masalah ini. Saya percaya pengelola Benang membuat pilihan yang tepat dalam penentuan prioritas. Jika menurut mereka masalah tersebut terlalu rendah prioritasnya, mereka berhak mengabaikan atau menutupnya.

Mohon maaf jika saya salah paham, dan Anda terlibat dalam memelihara repositori ini. Dalam kasus ini, silakan menutup masalah ini.

Tapi secara pribadi saya ingin menganggap apa yang Anda anggap sebagai pengalaman menakutkan bagi pemula untuk sesuatu yang "hampir tidak pernah bisa ditindaklanjuti".

Menginstal create-react-app dan kemudian menjalankan create-react-app myapp akan menghasilkan peringatan sebagai bagian dari instalasi:

warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

Peringatan npm bahkan lebih menakutkan:

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/react-scripts/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/react-scripts/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

Untungnya npm memungkinkan kita menentukan level log, yang tidak dimiliki Yarn. Sayangnya kami harus mengabaikan semua peringatan npm karena ini.

Mengapa peringatan ini menjadi masalah?

Bagi pengguna berpengalaman seperti Anda, itu bukan masalah. Tetapi Create React App adalah pintu masuk ke ekosistem React dan npm bagi banyak orang. Bagi sebagian orang, ini adalah titik masuk ke pengembangan web.

Mereka tidak tahu apa itu fsevents . Pesan tersebut berbunyi seolah-olah Buat Aplikasi React tidak kompatibel dengan Windows. Ini takeaway mereka. Sangat bagus jika semuanya berfungsi nanti, tetapi jika ada yang rusak, mereka tidak selalu melaporkan masalah karena mereka mendapat gagasan bahwa itu tidak seharusnya berfungsi berkat peringatan ini. Saya mencoba untuk melawan kesan ini dengan proposal ini.

Mengapa kita berbicara tentang menakutkan. Ini adalah pengembangan perangkat lunak, bukan taman kanak-kanak.

Asumsi bahwa orang hanya takut di taman kanak-kanak membuatku bingung. Ada banyak hal yang ditakuti orang sepanjang hidup mereka. Ini termasuk kondisi mental seperti kecemasan, dan ketakutan lainnya (misalnya takut Anda tidak cukup baik dalam pekerjaan Anda).

Ini mungkin tampak tidak terkait dengan alat JavaScript, tetapi sebenarnya tidak. Ada dua masalah terpisah di sini:

1. Peringatan yang tidak jelas dan tidak bisa ditindaklanjuti membuat orang cemas. Mereka membuat mereka kurang mempercayai alat mereka, dan membuat mereka bingung apakah mereka melakukan sesuatu yang salah meskipun sebenarnya tidak. Ini berkontribusi pada pengurasan kognitif yang dijelaskan dengan sangat baik oleh Kathy Sierra .

2. Suara peringatan yang tidak bisa ditindaklanjuti membuat orang mengembangkan titik buta untuk peringatan. Orang belajar untuk mengabaikan mereka. Setiap peringatan yang tidak bisa ditindaklanjuti berkontribusi pada biaya ini. Kami telah melihat sering terjadi dengan alat yang berbeda, bukan hanya Benang. Ini skenario "Anak laki-laki yang menangis serigala". Akibatnya, di masa depan orang gagal untuk mendiagnosis masalah dan menghabiskan waktu mereka dan pemelihara karena mereka melewatkan peringatan penting di lautan yang tidak penting.

Saya harap ini menjelaskan mengapa menurut saya hal ini perlu ditangani. Akan tetapi, saya tidak akan berpartisipasi dalam diskusi ini lebih lanjut karena Anda tampaknya sangat bersemangat untuk menolak proposal ini, dan saya tidak bersedia menginvestasikan lebih banyak energi pribadi untuk mendiskusikannya dengan Anda.

Ini adalah kedalaman informasi yang ingin saya dapatkan dari @gaearon. Terima kasih telah meluangkan waktu untuk menjelaskan karena tampaknya empati Anda untuk pelajar bersinar dan itu terpuji.

Saya merasa penting untuk mengajari peserta didik memancing sendiri. Dan terkadang itu berarti tidak melindungi mereka dari ketakutan mereka, melainkan mendorong mereka untuk menghadapi rasa takut secara langsung.

Dalam kasus peringatan fsevents , bahkan sebagai ketergantungan opsional, pelajar harus didorong untuk mengamati peringatan tersebut dan berusaha untuk memahaminya. Jika tidak, mereka tidak akan tumbuh.

Pencarian cepat Stack Overflow, misalnya, menyajikan solusi berikut untuk menangani pesan peringatan yang dijelaskan: https://stackoverflow.com/a/42938398/712334.

Jika overhead kognitif menjadi perhatian, maka saya akan mendorong seseorang untuk mencari alat yang berbeda untuk membuat aplikasi satu halaman mereka atau untuk memulai perjalanan pengetahuan mereka di suatu tempat yang lebih cocok untuk mendapatkan dasar-dasar Web.

@ glen-84 apakah Anda mau membagikan pendapat Anda, atau hanya mengacungkan jempol?

Tentu.

• Menampilkan peringatan tentang sesuatu yang tidak dapat ditindaklanjuti dan tidak menyebabkan masalah apa pun menghasilkan:
  
  
  
  • Waktu yang terbuang oleh pengembang terlebih dahulu harus mencari tahu mengapa itu terjadi, dan kemudian harus mengabaikannya setiap kali (dan mengabaikan peringatan adalah hal yang buruk)
  
  
  • Waktu yang terbuang oleh pengembang Yarn / npm, harus menjelaskan mengapa hal itu terjadi
  
  
  • Kesalahan perkakas downstream
  
  
  • dll.
  
  
• Jika Anda menggabungkan suara dari masalah npm, hampir 150 pengguna setuju.
• Pengembang npm telah menerima perubahan tersebut, dalam teori.

Saya tidak memilih dua komentar Anda, karena IMO mereka tidak menambah nilai pada diskusi ini.

Saya setuju bahwa peringatan yang tidak dapat ditindaklanjuti tidak berguna dan juga dapat menjadi menakutkan / berisik /. Mari kita ikuti saran @dmbdesignpdx seperti yang disarankan

Humas disambut.

Waktu yang terbuang oleh pengembang terlebih dahulu harus mencari tahu mengapa itu terjadi, dan kemudian harus mengabaikannya setiap kali (dan mengabaikan peringatan adalah hal yang buruk)

Anda tidak mengabaikannya. Anda belajar mengapa itu terjadi dan mengambil tindakan. Terkadang hal itu akan mengarah ke perangkat lain atau masalah dalam repo yang menangani akar masalah seperti yang disarankan oleh @Vanuan dalam masalah NPM terkait.

Waktu yang terbuang oleh pengembang Yarn / npm, harus menjelaskan mengapa hal itu terjadi

Bukan tanggung jawab Yarn untuk mengatasi masalah dari repositori individu atau manajer paket. Dan NPM bukan satu-satunya pengemas di luar sana. Dan secara pribadi saya lebih suka melihat Benang tumbuh untuk menggantikan Komposer dan mengisi kekosongan Bower yang baru saja meninggalkan komunitas daripada terganggu oleh ikan haring merah.

Jika Anda menggabungkan suara dari masalah npm, hampir 150 pengguna setuju.

Itu argumentum ad populum. Desain oleh komite tidak pernah berhasil dengan baik untuk siapa pun.

Menghapus label cat-discusson sejak kita berdiskusi dan sekarang kita memiliki tindakan yang harus dilakukan: buat peringatan lebih berguna dengan menyatakan paket mana yang bergantung pada paket lain yang tidak digunakan lagi.

@jhabdas Saya pikir kita setuju pada bagian "belajar" dan "mengambil tindakan". Bagian yang tampaknya tidak terlalu kita setujui adalah bagaimana kita melakukannya dan apakah itu tugas yarn s atau tidak. Untuk saat ini saya pikir benang yang lebih bermanfaat bagi penggunanya, semakin baik. Yang mengatakan saya tidak akan memprioritaskan ini sangat untuk mengambil sumber daya dari perbaikan dan pembaruan yang lebih penting, oleh karena itu kami tunduk kepada komunitas untuk PR.

Jika ada yang ingin membahas lebih lanjut tentang masalah ini, mari kita pindahkan ke Discord. Anda bisa langsung ping saya ke sana untuk menarik perhatian saya. 💓

Anda belajar mengapa itu terjadi dan mengambil tindakan

Tindakan apa yang harus kita ambil?

Bukan tanggung jawab Yarn untuk mengatasi masalah dari repositori individu atau manajer paket.

Pengembang Yarn dan npm-lah yang akan melihat masalah yang dilaporkan berulang kali terkait masalah ini, dan harus menghabiskan waktu dengan triase masalah yang tidak perlu alih-alih mengerjakan fitur baru dan perbaikan bug.

Itu argumentum ad populum. Desain oleh komite tidak pernah berhasil dengan baik untuk siapa pun.

Hanya itu yang kami miliki saat ini, dan jika Anda tidak setuju dengan perubahan ini, maka suara negatif Anda tentang masalah ini akan membantu pengelola dalam pengambilan keputusan.

Okay @ glen-84 dengan ramah mengingatkan saya bahwa masalah aslinya bukanlah tentang sub dependensi dan pesan informatif tetapi tidak memperingatkan tentang paket yang tidak dapat diinstal pada platform tertentu.

Jadi sekarang tindakan untuk tiket khusus ini adalah dengan menurunkannya dari peringatan ke info atau debug karena tidak menambah nilai. Keberatan? Pindah bagian lainnya ke # 3869.

@gaearon Perubahan kode satu baris tanpa pengujian unit dibuat untuk mengatasi masalah ini. Harap diingat itu.

@jhabdas sudah saya jawab di PR. Ini adalah filosofi saya https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565, tetapi jika menurut Anda kompatibilitas paket atau bagian itu secara khusus memerlukan beberapa pengujian, harap buka permintaan tarik dan terima kasih sebelumnya :)

Saya percaya penilaian Anda yang baik tetapi saya percaya BANGET sejauh saya bisa melempar ranting. Tapi tidak apa-apa. Saya ingin mengirim pesan saya untuk kepentingan orang lain untuk melihat bagaimana perubahan kode satu baris dapat menghindari seluruh utas ini. Terkadang tindakan berbicara lebih keras daripada kata-kata. Bersulang.

@jhabdas sebesar saya menghargai kontribusi Anda, saya ingin mengingatkan Anda kode etik kami , khususnya item berikut:

• Menggunakan bahasa yang ramah dan inklusif
• Menghormati sudut pandang dan pengalaman yang berbeda
• Menunjukkan empati terhadap anggota komunitas lainnya

Maafkan saya yang tulus. Saya akan meninjau kode etik dan mencoba melakukan yang lebih baik untuk menjadi warga komunitas yang baik. Terima kasih telah mengarahkan saya ke arah yang benar, @BYK.

Terima kasih telah memperbaikinya. 😍 🙇

Itu adalah masalah pilihan teratas di NPM dengan selisih lebar dan menyebabkan masalah nyata, namun setelah 1,5 tahun tidak mengatasinya, bot mereka menutupnya secara otomatis karena terlalu tua!

Manajemen proyek semacam itu adalah salah satu alasan saya beralih ke Yarn.

Melihat betapa mudahnya memperbaikinya, sungguh menyedihkan betapa banyak waktu dan upaya yang terbuang untuk ini. 😢

Terima kasih!

Hai, terima kasih atas semua upaya tentang ini. Jauh lebih baik bahwa sekarang pada stdout saya daripada stderror;). Namun bahkan tingkat info akan membawa ke sini banyak orang. Dan satu-satunya keluaran yang akan mereka peroleh setelah satu jam membaca masalah terkait adalah bahwa mereka perlu menerimanya untuk saat ini (yang tidak menggunakan babel) dan bahwa membuat pengoptimalan khusus platform melalui dependensi opsional dimungkinkan tetapi dengan biaya peringatan manajer paket kepada pengguna. Saya di sisi memiliki keluaran ini hanya pada tingkat debug.

@kubino, itu tanggapan yang bagus, terima kasih! Kami sadar bahwa memindahkannya ke info tidak akan memperbaikinya untuk selamanya. Untuk itu @jhabdas sebenarnya meluangkan waktu untuk membuatnya lebih baik dan umum dan mengajukan RFC . Apakah Anda tertarik untuk memberikan umpan balik di sana dan memberi tahu kami jika RFC menjawab kekhawatiran Anda?

@BYK terima kasih karena masih tertarik dengan ini. Saya jauh dari ahli dan mungkin saya salah. Anda mengarahkan saya ke RFC dengan judul "buat peringatan sub-paket yang tidak berlaku lagi menjadi lebih informatif". Saya pikir mengirimkan peringatan TIDAK DIGUNAKAN LAGI kepada pengguna sudah benar secara default (meskipun memiliki cara untuk menekan peringatan paket tertentu mungkin akan baik).
Perhatian saya adalah tentang ketergantungan OPSIONAL yang hanya berfungsi sebagai pengoptimalan untuk beberapa platform beton, di sana saya melihat nilai yang sangat sedikit dari pencemaran, sebaliknya keluaran Benang bersih yang begitu indah. Tapi seperti yang saya katakan, saya bukan ahli dan saya tidak yakin apakah ini selalu begitu jelas untuk ditentukan

@kubino tidak perlu jadi ahli. Anda tahu bahwa dunia ini penuh dengan pakar yang mengaku diri sendiri, jadi lebih baik Anda mengaku sebagai bukan pakar dan mungkin Anda akhirnya akan menjadi ahli 😀

Bagaimanapun, saya belum punya waktu untuk membaca RFC itu sepenuhnya tetapi saya pikir itu termasuk dalam bagian label = "Interoperability" . Yang mengatakan mungkin kita harus menambahkan bagian optimization untuk kasus ini. Karena itu mari kita lanjutkan diskusi tentang PR itu dan saya pikir Anda harus membuat saran ini di sana dan lihat apa pendapat @jhabdas tentang itu.

@kubino Saya telah memperbarui deskripsi

RFC adalah proposal untuk mencoba dan membantu menangani sejumlah kasus penggunaan terkait yang mungkin muncul dengan memperkenalkan fitur kecil (yang tampaknya tidak terkait) yang, bila digunakan secara kreatif, bermaksud untuk membantu memenuhi kebutuhan seperti yang Anda ajukan sementara juga menambahkan manfaat tambahan pada pekerjaan hebat yang telah dicapai Yarn bagi komunitas.

Berbahagialah untuk mendiskusikan dan menggunakan wawasan Anda untuk lebih meningkatkan RFC, karena saya telah belajar menjadi lebih berpengalaman bisa menjadi lebih banyak atau lebih dari kewajiban karena dapat menjadi aset dalam hal pengkodean.

@BYK Saya tahu di mana Anda menunjuk;) Tentu saya harus setuju dengan Anda berdua @jhabdas , solusi umum adalah satu-satunya jalan keluar dari diskusi ini. Kategorisasi pesan adalah langkah pertama yang akan mengaktifkan yang lainnya ... mari kita lanjutkan diskusi di RFC terkait. Terima kasih!

Jika itu opsional "diberi OS target", maka itu seharusnya tidak menjadi tingkat WARN. Penulis berkata "Jika MacOS maka gunakan FSEvents, jika tidak jangan." Jadi, jika Anda menginstal di OS selain Mac, mengapa harus diperingatkan? Ini lebih seperti info / debug.

@robertjchristian Saya rasa ada dua aspek untuk ini:

1. fsevents itu sendiri tidak berfungsi di luar macOS jadi upaya untuk menginstalnya pada OS semacam itu akan mencetak peringatan atau kesalahan. Beberapa paket yang menggunakan fsevents mungkin bergantung pada API-nya secara universal (salah) tanpa mengetahui bahwa itu hanya untuk macOS dan merusak OS lain dalam prosesnya.
2. Jika fsevents adalah untuk beberapa paket yang hanya diperlukan di macOS, paket tersebut seharusnya dapat menandai fsevents sebagai tidak-untuk-diinstal di luar macOS. Kegagalan untuk menginstal fsevents di macOS akan mengakibatkan kegagalan tetapi di OS lain bahkan tidak akan ada upaya untuk menginstal.

Masalah intinya adalah memperlakukan fsevents sebagai ketergantungan opsional merupakan pendekatan yang salah. Apa yang hilang adalah kemampuan untuk menandai fsevents seperti yang diperlukan di macOS dan sebagai benar-benar dikecualikan, bukan hanya opsional, di OS lain.

Ya, itu dijelaskan beberapa kali di utas aslinya, sepertinya tidak ada yang mendengarkan:

https://github.com/npm/npm/issues/11632#issuecomment -238217690

Solusinya adalah menambahkan dukungan dependensi khusus platform.

https://github.com/npm/npm/issues/11632#issuecomment -257214969

solusi yang 'benar' adalah memiliki beberapa metode dependensi bersyarat - cara untuk sebuah paket untuk menunjukkan bahwa satu atau lebih dependensinya tidak boleh diinstal pada beberapa platform. Ini tidak sama dengan paket yang mendeskripsikan dirinya sebagai platform khusus - sebuah paket tidak tahu apakah itu opsional atau tidak, jadi yang bisa dikatakan adalah 'jika Anda menginstal saya di platform yang salah, itu adalah kesalahan'.

https://github.com/npm/npm/issues/11632#issuecomment -300804918

Inilah yang bisa dilakukan npm:

1. Ubah dependensi opsional dan pesan yang tidak didukung dari WARN ke INFO (yang diinginkan kebanyakan orang).
2. Menerapkan dependensi khusus platform (solusi yang tepat)

Jadi, alih-alih menyembunyikan peringatan, mereka seharusnya memperbaikinya dengan menerapkan dependensi bersyarat. Tapi itu membutuhkan perubahan spesifikasi package.json. Saya membayangkan sesuatu seperti ini:

  "conditionalDependencies": {
    {
      "condition": { "platform": "darwin" }, // 'darwin', 'freebsd', 'linux', 'sunos' or 'win32'
      "packages": { "fsevents": "^1.0.0" }
    }
  },

Alternatif lain untuk penulis fsevents:

Jadikan tidak gagal pada platform non OSX tanpa peringatan apapun, cukup pesan INFO tentang platform tidak didukung

Tapi itu tidak jauh berbeda dengan menyembunyikan peringatan di level npm.

Masih belum ada jawaban? Peringatan itu sangat mengganggu.

Pada titik ini saya tergoda untuk hanya membeli Mac dengan tujuan tidak melihat ini selama empat tahun lagi meskipun saya benci sistem operasinya 👎

Pada titik ini saya tergoda untuk hanya membeli Mac dengan tujuan tidak melihat ini selama empat tahun lagi meskipun saya benci sistem operasinya 👎

Jika Anda mengembangkan perangkat lunak secara profesional, saya tidak dapat merekomendasikan investasi yang lebih baik.

Mengapa menampilkan peringatan jika Anda tidak meminta pengguna melakukan sesuatu untuk memperbaikinya?

Semuanya Berdebat untuk menepati peringatan, harap pikirkan sejenak. Jika pengguna tidak dapat melakukan apa pun untuk memperbaiki peringatan ini, mengapa kami menampilkannya?

Ini seperti pasangan Anda memberi tahu Anda bahwa mereka lapar, Anda seperti memasak untuk diri sendiri, mereka tidak akan melakukannya, Anda memasak mereka tidak akan makan, tetapi terus mengganggu Anda, saya lapar. Setiap kali Anda menyapa (npm install / yarn), mereka bilang saya lapar (WARN WARN WARN) .. Sepertinya tidak ada gunanya bagi saya.

Pada titik ini saya tergoda untuk membeli Mac hanya dengan tujuan tidak melihat ini

Apakah maksud Anda Anda tidak akan melihat ini di Mac?
Nah, Anda tidak akan melakukannya kecuali Anda menggunakan buruh pelabuhan:

MacbookPro $ docker run -ti --rm node yarn add [email protected]
yarn add v1.13.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

Saya pikir Anda akan lebih beruntung membagi chokidar dan menghapus fsevents dari sana.
Node terbaru mengalami peningkatan besar dengan dukungan asli fs.watch di OS X.

Tentu saja, Anda juga harus membayar lusinan paket tergantung pada chokidar

Cobalah mengeluh di sini untuk perubahan:
https://github.com/paulmillr/chokidar/issues

Saya pikir Anda akan lebih beruntung membagi chokidar dan menghapus fsevents dari sana.
Node terbaru mengalami peningkatan besar dengan dukungan asli fs.watch di OS X.

Sepertinya kita berada di halaman yang sama . xD

Ya, saya kira satu-satunya pilihan untuk menunggu sampai chokidar menjatuhkan dukungan untuk node 10 di mana titik itu akan menjadi tidak berguna dan proyek lain mulai menjatuhkannya.

@Vanuan dukungan node.js baru-baru ini untuk fs.watch masih buruk. Coba gunakan di seluruh platform.

Jika Anda ingin mengeluh tentang peringatan instalasi, mungkin mengeluh kepada pengelola yang "menghentikan" paket. Itu sangat menyebalkan. Ini tidak terjadi di masa lalu. Fsevents jauh lebih sedikit masalah dibandingkan dengan ini.

Apakah ini tidak akan pernah bisa diperbaiki?