Yarn: Tambahkan paket tanpa menyimpan ke package.json

Dibuat pada 9 Nov 2016  ·  96Komentar  ·  Sumber: yarnpkg/yarn

Sepertinya tidak ada kemungkinan untuk memasang paket menggunakan benang tanpa menyentuh package.json? (seperti npm install tanpa --save params). Bukankah fitur seperti itu harus ditambahkan?

Komentar yang paling membantu

Saya tidak mengerti mengapa pemiliknya begitu beropini tentang hal ini. Jika Anda tidak melihat penggunaannya, bukan berarti tidak ada. Saya percaya jika orang memintanya, itu berarti mereka membutuhkannya, dan mereka tidak terlalu bodoh.
Menambahkan opsi --no-save opsional akan menyelesaikan masalah beberapa orang dan tidak membawa kerugian sama sekali.

Semua 96 komentar

Tidak, fitur ini sengaja ditinggalkan. Ini dianggap berbahaya untuk menginstal paket tanpa tercermin di package.json. Mengapa Anda ingin hal seperti itu ada?

Dari pengumuman Facebook

Kami menghapus perilaku "ketergantungan tak terlihat" dari npm installdan pisahkan perintahnya. Menjalankan yarn add <name> sama dengan menjalankan npm install --save <name> .

Saya sering menggunakan fitur itu untuk menguji berbagai hal. Terutama ketika saya bekerja dengan perpustakaan yang saya pelihara dan perlu menginstal versi lokal (yang membuat file: dep) hanya untuk menguji perubahan saya sebelum membuat rilis.

Meskipun saya setuju implementasi npm untuk melakukannya secara default adalah pilihan yang buruk, saya pikir ini adalah sesuatu yang berguna ketika digunakan secara eksplisit.

Ya saya pikir membiarkannya dilakukan dengan bendera eksplisit akan menyenangkan untuk dimiliki, saat ini untuk yang satu ini masih dapat menggunakan npm i =) tetapi hanya untuk menghilangkan kebutuhan npm.

Kami secara eksplisit tidak mendukung ini karena ini adalah perubahan penting ke node_module yang akan dihapus dengan yarn install s berikutnya karena kami menganggap package.json dan yarn.lock menjadi sumber kebenaran.

Kami memiliki ketergantungan yang tidak dapat diinstal dengan mudah di windows (libxslt) jadi:

  • Untuk windows: pengembang mengekstraknya di node_modues mereka
  • Untuk linux: pengembang menginstalnya tanpa menyimpan (jika di package.json maka pengembang yang menggunakan windows tidak dapat melakukan instalasi apa pun karena build akan gagal)

Apakah ada cara yang bersih untuk melakukannya dengan menggunakan benang (atau cara lain yang lebih baik untuk mencapai hasil ini)?

(Saya setuju dengan Anda bahwa paket harus tercermin dalam package.json, tetapi di sini saya tidak dapat menemukan solusi bersih)

@GuillaumeLeclerc Bagaimana dengan yarn add -D xxx dan menghapus sendiri entri dari package.json?

Ini akan dihapus saat paket lain ditambahkan? Bukan?

@GuillaumeLeclerc Sayangnya, ya.

@GuillaumeLeclerc Anda mungkin ingin membersihkan komentar Anda ...

Harap tambahkan argumen seperti yarn add --no-save sehingga saya dapat menginstal modul tanpa mengubah package.json atau yarn.lock saya. Saya sering mendapati diri saya perlu menguji modul sebelum melakukannya.

Saya tidak dapat menggunakan normal npm install karena saya mendapatkan "Ukuran tumpukan panggilan maksimum terlampaui". Jadi benang adalah satu-satunya cara yang layak untuk dipasang.

Tolong jangan buat saya mengembalikan perubahan ke package.json yarn.lock!

Bagi saya, ini menggigit saya karena saya mencoba menginstal peerDep. Yarn tidak memiliki cara untuk menginstal deps rekan selama install jadi saya harus melakukannya secara manual. Saya tidak bisa yarn add <package> tanpa menambahkannya ke package.json / yarn.lock. Aku terjebak.

@viveleroi ini terdengar sangat benar. Mengapa Anda ingin menginstal dependensi peer tanpa menambahkannya ke package.json ?

@hpurmann Karena itu menduplikasi peerDependencies menjadi dependencies (atau devDependencies jika saya menggunakan --dev ). Jika itu yang dimaksudkan maka itu pasti tidak intuitif.

@hpurmann Saya ingin mempublikasikan komponen react, jadi react shoulde a peerDep. Namun, saya perlu menginstal react dalam proyek untuk mengembangkannya.

cukup tambahkan --no-save => itu sangat penting
saya perlu melewatkan dependecy opsional tertentu untuk paket tertentu. saya tidak bisa melakukan itu dengan benang Anda. mungkin dengan opsi --tidak simpan saya dapat mengerjakannya di sekitar

Karena yarn link local-pkg tidak menginstal dependensi local-pkg di aplikasi host, saya ingin menginstalnya secara langsung tetapi tidak menyimpannya ke app package.json karena mereka akan dibawa oleh local-pkg setelah dipublikasikan .

Saya tidak mengerti mengapa pemiliknya begitu beropini tentang hal ini. Jika Anda tidak melihat penggunaannya, bukan berarti tidak ada. Saya percaya jika orang memintanya, itu berarti mereka membutuhkannya, dan mereka tidak terlalu bodoh.
Menambahkan opsi --no-save opsional akan menyelesaikan masalah beberapa orang dan tidak membawa kerugian sama sekali.

Saya mencoba menggunakan Yarn untuk proyek NodeJS yang dijalankan di AWS Lambda. Saya agak terkejut mengapa fitur ini tidak didukung. Kasus penggunaan saya adalah saya perlu menginstal aws-sdk di lingkungan dev lokal saya, tetapi saya tidak ingin disimpan di package.json karena AWS Lambda sudah menginstal ini di lingkungan mereka. Memasukkan aws-sdk berarti paket akhir kita akan membengkak.

benang link dan benang add tidak bisa hidup bersama. thread add bergantung pada package.json sementara yarn link hanya menghubungkan paket lokal ke lokasi lain.

Misalkan Anda mengembangkan paket X yang bergantung pada Y, Anda berdua adalah pengembang X dan Y sehingga Anda menyimpan X dan Y secara lokal dan menautkan Y ke direktori X. Saat Anda menambahkan benang di X, hal itu akan menghapus tautan ke Y.

Bagaimana Anda menyiasatinya?

~ Untuk kasus seperti itu, Anda cukup menggunakan perintah npm untuk menginstal tanpa membuat footprint pada paket json atau yarn.lock: ~

~ npm install [packages ...] --no-save --no-package-lock ~

seperti yang dikatakan @heikomat di bawah ini, karena npm5 menggunakan pemangkasan otomatis setelah pemasangan (lihat https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921) bukan pilihan dan dapat merusak folder node_modules Anda sepenuhnya.

ok jadi sekarang saya tidak bisa hidup tanpa npm

Saya menggunakan npm install di salah satu skrip saya yang menginstal dependensi sub-modul lokal ke node_modules utama. Ini berfungsi dengan baik dengan npm4, tetapi sepenuhnya rusak dengan npm5, karena npm5 hanya memutuskan untuk memasukkan beberapa paket selama penginstalan -.- (lihat https://github.com/npm/npm/pull/18921)

Untuk alasan itu, saya mencoba mengganti npm install di skrip saya dengan benang, tetapi saya tidak bisa melakukannya, jika benang selalu menyentuh package.jsons dari submodules lokal selama instalasi, setidaknya bukan tanpa skrip saya menjadi berantakan dan "membersihkan" demi benang

Anda sudah memiliki opsi --no-lockfile , jadi itu membuat folder node_modules keluar dari pikiran,
tetapi devs masih perlu memiliki solusi untuk menjaga package.json tidak dapat diubah.

Terima kasih.

Saya suka bagaimana setiap kali seseorang menjelaskan kasus penggunaan khusus mereka untuk memasang modul tetapi tidak merekamnya, pengelola kembali masuk dan melafalkan shibboleth mereka. Harus membuatnya mudah untuk merasa percaya diri dengan sikap keras kepala Anda jika Anda dapat menerima permintaan yang sama dari banyak orang yang berbeda ini sebagai permintaan yang datang dari mereka yang menderita kegagalan moral. Sebagai kompromi, mungkin kita bisa menamai sakelar --i-am-a-heritic-and-a-bad-programmer ?

Sedih melihat satu kelemahan utama yarn dipertahankan dari npm adalah kebenciannya terhadap siapa pun di luar organisasi mereka.

Dan dalam kasus saya, saya ingin menggunakannya sebagai solusi untuk masalah # 4297 :)
Membatasi pengembang secara artifisial untuk melakukan sesuatu dapat membuat produk Anda tidak dapat digunakan dalam situasi tertentu.

Tunggu apa kamu bercanda? Ini adalah parodi. Harap berhenti mendikte bagaimana setiap alur kerja pengembang seharusnya bekerja. Inilah mengapa NPM tidak cocok untuk kami dan kami pindah ke Yarn. Ideologi bahwa "package.json dan yarn.lock harus menjadi sumber kebenaran" tidak masuk akal. Paket harus dapat diinstal tanpa mengubah kode sumber. Sederhana seperti itu.

Ayolah, pengelola. Jelas ada kebutuhan nyata untuk ini oleh komunitas. Tolong berhenti menghentikan percakapan cerdas dengan filosofi yang tidak difilter dan salah tempat.

Sekarang saya menemukan bahwa yarn mematahkan tes saya karena saya memiliki modul di mana saya perlu menguji require dan untuk menguji mengharuskan saya mengkomit modul contoh ke ./node_modules . Yarn menghapus modul contoh ketika saya menjalankan yarn install . Lebih banyak tentang "sumber kebenaran", saya berasumsi.

kasus penggunaan: Alat yang saya gunakan membutuhkan paket. Tim tidak menggunakan alat itu. Tim (secara wajar) tidak ingin paket itu diinstal.

Ini sangat membuat frustrasi saya menggunakan codelyzer untuk panduan gaya bersudut, tetapi tim saya lainnya tidak dan tidak memengaruhi fungsionalitas kode. Satu-satunya cara untuk membuatnya berfungsi sekarang, adalah menambahkannya ke kunci benang saya dan anggap saja kunci benang saya belum benar-benar berubah atau menggunakan npm meskipun tim saya menggunakan benang. Keduanya adalah pilihan yang mengerikan.

Ini sudah 2018 tetapi fitur ini belum ditambahkan meskipun banyak kasus penggunaan yang valid.

Hanya untuk memberikan contoh lain mengapa ini mungkin berguna:

Kami memiliki skrip yang secara otomatis memperbarui dependensi dengan menginstal versi baru, menjalankan tes dan KEMUDIAN menyimpannya ke package.json / *.lock dan melakukan perubahan itu ATAU memutar kembali jika ada kesalahan. Jauh lebih mudah untuk menjalankan yarn lagi daripada mengingat versi lama dan secara eksplisit adding itu lagi.

Selain itu, rasanya lebih bersih untuk tidak mengubah satu titik kebenaran Anda ( package.json ) sebelum "benar-benar" memastikan bahwa Anda benar-benar dapat memperbarui ketergantungan ini tanpa merusak tes. Untuk saat ini Anda mendapatkan package.json (meskipun sementara) berisi ketergantungan yang merusak kode Anda.

Ada banyak kasus penggunaan yang valid untuk masalah ini. Akankah pengelola yarnpkg bersedia menerima PR jika akan dibuat?

ping @kittens jika Anda masih berafiliasi dengan proyek ini ...

Sementara itu, saya menggunakan skrip berikut di bagian scripts dari package.json :

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

Saya berasumsi ada alternatif untuk benang?

Tidak ada alternatif, npm5 berantakan seperti hidup saya.

Dan jangan lupa untuk menyalin symlink di folder .bin. ;)

Bagi saya chmod 444 package.json dan yarn add XXXX --no-lockfile setidaknya bekerja di sekitar masalah untuk pengembangan dan pengujian lokal.
Penambahan berakhir dengan kesalahan izin (diharapkan), tetapi modul yang ditambahkan ada di node_modules sesudahnya dan saya dapat menguji dengan dependensi peer yang diinstal secara lokal tetapi tidak bertahan di package.json tetapi sebagai dependensi peer.

Saya terkadang memerlukan pustaka debugging untuk sementara, seperti why-is-node-running . Saya tahu saya ingin membuangnya setelah sekali penggunaan, dan opsi --no-save akan memungkinkan saya menginstal-dan-melupakan, tanpa menjalankan risiko mencemari dependensi saya.

Saya menggunakan Lerna, dan saya benar-benar hanya ingin menginstal _only_ Lerna di salah satu langkah CI saya, untuk tahap publikasi, karena proyek ini sudah dibangun pada langkah sebelumnya dan artefak telah dipindahkan. Apakah itu skenario yang valid?

Saya akan menghemat beberapa langkah, jika fitur ini akan tersedia.
node_modules ada di .gitignore.

Dari pada:

git clone external-package (needed for temp testing only)
yarn install
yarn link

kembali ke repo asli saya
yarn link external-package

hanya:
original-repo:
yarn install external-package --no-save

Sebagai bagian dari pipeline build kita, kita perlu menginstal nsp dan menjalankannya, mengekspor dependency-check.xml.

Saya tidak mengerti mengapa pemasangan alat sederhana ini perlu tercermin dalam daftar paket, itu hanya berarti saya sekarang perlu melakukan git checkout ${BRANCH_NAME} untuk membatalkan modifikasi sebelum saya dapat mendorong tag.

Saya tidak mencoba mengubah sumber. Saya tidak mau dan ini bukan urusan saya, itu terserah tim pengembang di organisasi saya. Anda membuat hidup saya sedikit lebih sulit untuk beberapa filsafat abstrak. Hentikan.

Tahu, mengapa masalah ini ditutup? Apakah tombol --no-save telah ditambahkan dalam PR?

Ada kalanya saya ingin mengubah versi modul yang dibawa dari sebuah ketergantungan. Misalnya, @types/sinon dibawa oleh ketergantungan dev lain baru-baru ini merusak tsc saya. Saya tidak ingin @types/sinon ke dependensi dev saya, tetapi saya ingin mengubah versinya secara manual dengan yarn add @types/[email protected] --no-save agar saya dapat terus bekerja. Sebagai gantinya, saya hanya beralih kembali ke npm. Sangat membuat frustrasi.

Saya memiliki ketergantungan hanya produksi (appdynamics) yang merupakan peretasan sendiri dari binari khusus platform. Ternyata kami bahkan tidak membutuhkannya di mesin pengembang. Menambahkan yarn add ... --no-save akan memungkinkan kita menerapkan dengan bersih tanpa skrip yang membahayakan package.json (terutama karena package.json, sayangnya, tidak dapat memiliki komentar yang menjelaskan tujuan setiap skrip atau ketergantungan)

cc @kittens @hpurmann

Harap atasi masalah yang sangat populer ini atau kunci sebagai penyelesaian. Akan sangat dihargai jika memiliki jawaban konkret sebagai tanggapan atas semua kritik yang diajukan di atas.

Dan komunitas siap menyediakan fitur tersebut, beri tahu kami jika Anda menerima permintaan penarikan tersebut. Terima kasih.

haha, masih belum diimplementasikan, niiiiice

Mengapa Anda ingin hal seperti itu ada?

Adalah hal yang sama persis dengan yang dikatakan orang tentang BEJ ketika pertama kali mengeluarkan template campuran dan logika. Jika memungkinkan dan memiliki kegunaannya sendiri, pertanyaan yang benar adalah mengapa tidak? Maksud saya ini adalah bendera, itu bukan perilaku default sehingga Anda memberi tahu benang secara eksplisit (alias saya tahu apa yang saya lakukan).

@kittens @hpurmann
Saya memiliki beberapa paket berdasarkan react dan ini memiliki ketergantungan sub-modul satu sama lain. jadi saya telah react dan react-dom sebagai peer-dep tetapi ketika saya perlu membangun paket ini secara individual, saya perlu react dan react-dom.
Saya kira ini akan menjadi kasus penggunaan yang tepat untuk menginstal paket secara lokal tanpa menambahkannya sebagai dep.
Saya tidak ingin menggunakan npm untuk penggunaan yang sepele dalam proyek saya.
Setiap pembaruan, menunggu sesuatu yang mirip dengan --no-save .
Saya kira tidak ada salahnya menambahkan fitur jika komunitas menuntut, dengan asumsi pengembang mengetahui efek sampingnya (kehilangan paket lokal segera setelah Anda menjalankan pemasangan benang.)
Terima kasih

Trik praktis adalah yarn add --dev pkg && yarn remove pkg . Itu melakukan hal yang sama. Lockfile tetap seperti sebelumnya, begitu tak tersentuh.

Ini disebutkan oleh @Legends sebelumnya tetapi perlu ditekankan:

Salah satu solusi untuk beberapa kasus adalah menginstal paket yang diperlukan di folder terpisah dan yarn link paket yang diperlukan ke mana pun paket itu seharusnya ditambahkan. Ini tidak ideal tetapi bisa membantu.

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorb pasti tidak layak, imho. add + remove persis seperti yang dilakukan dengan --no-save dalam npm. Itu tidak mengacaukan tautan sistem dan tidak menyentuh file kunci dengan cara yang buruk - artinya itu sama setelah yarn remove .
Belum lagi jika Anda ingin melakukan hal itu secara terprogram maka pasti membuat dirs, menghubungkan dan lain-lain bukanlah cara yang tepat.

beberapa kasus

Sebagai contoh? Yang cukup aneh pasti?

@hpurmann @kittens

Jadi apa praktik yang direkomendasikan untuk mengembangkan paket dengan dependensi peer?

Jika saya memiliki misalnya React as a peerDependency di paket saya, haruskah saya menambahkannya sebagai devDependency juga agar impor diselesaikan?

Lihat https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json Saya kira jawabannya adalah ya

Ada beberapa situasi untuk menggunakan fitur ini.

Sama seperti dalam siklus hidup CI saya menambahkan beberapa reporter cakupan. Tapi saya tidak bisa membawa mereka ke package.json kemudian mempengaruhi untuk menerbitkan NPM .

Simpan atau tidak simpan, saya pikir pilihan ini harus terserah pengembang itu sendiri bukan alatnya.

Baiklah, mari kita coba lihat ini dari sudut pandang pengelola. Saya pasti bisa melihat kelemahan dari solusi --no-save naif. Kami tidak mendapatkan penjelasan yang sangat lengkap di sini, tapi saya akan mencoba membangun manusia baja. Mungkin mereka bisa mengoreksi saya. Mungkin kita bisa menemukan kompromi. @kittens @hpurmann

(Maaf, ini berakhir lebih lama dari yang saya inginkan.)

Manajemen ketergantungan untuk aplikasi Node dan web modern agak kacau. Namun, kami menginginkan sistem yang memberi kami otomatisasi yang andal serta tingkat kontrol dan prediktabilitas tertentu, dengan fitur seperti deduplikasi dan build yang dapat direproduksi.

Untuk memahami kerumitan, kita perlu mengetahui apa yang diinstal dan mengapa, dan kita membutuhkan satu sumber kebenaran untuk menyelesaikan setiap ketidakkonsistenan. Dengan risiko menyatakan yang sudah jelas, node_modules itu sendiri tidak dapat memenuhi salah satu peran tersebut. Ini terlalu lambat untuk dilintasi, terlalu besar untuk ditransmisikan, terlalu rumit untuk kontrol versi, dan tidak dapat menyandikan aspek 'mengapa'. Itulah mengapa kami memiliki package.json dan yarn.lock .

Yarn merangkum kompleksitas node_modules dengan memberi kami akses terbatas melalui sebuah antarmuka. Jika kami berjanji untuk tidak merusak enkapsulasi, kami mendapatkan jaminan tertentu sebagai gantinya, seperti deduplikasi dan build yang dapat direproduksi. Jika kita menginstal sesuatu di node_modules tanpa perubahan yang sesuai pada package.json dan yarn.lock , kita kehilangan jaminan tersebut.

Selain itu, itu adalah kontrak tak terucapkan yang tidak disadari oleh banyak pengembang. Ketika mereka memecahkannya, mereka tidak melakukannya dengan sengaja. Jadi jika ada yang salah, Yarn mungkin disalahkan secara tidak adil. Plus, membuat alat yang sulit untuk Anda lakukan bukanlah filosofi desain yang buruk.

Namun , saya dapat melihat beberapa alasan untuk berkompromi:

  • Sepertinya ada kebutuhan yang pasti di sini. Lihat saja banyak kasus penggunaan yang tercantum dalam komentar di atas, dan rasio 'suka' / 'tidak suka'. Sikap keras kepala pengelola dalam menghadapi respons sepihak tidak membuat Yarn terlihat terlalu bagus.

  • Ada solusi yang dapat ditemukan yang mungkin berhasil untuk semua orang. Misalnya, perkenalkan file baru yarn.local.lock . Pengembang akan memasukkannya ke dalam .gitignore , dan ini akan menyimpan catatan dari semua paket yang diinstal dengan tanda --no-save dan dependensinya.

    Untuk menjaga agar yarn.lock terisolasi dari ini, deduplikasi dan perataan pohon ketergantungan 'lokal' dibatasi. File kunci lokal dapat beradaptasi agar sesuai dengan versi di file kunci utama (dan dedupe dalam hal ini) tetapi tidak sebaliknya. Akibatnya, banyak dependensi lokal transitif mungkin tidak diratakan menjadi node_modules .

    Dengan solusi ini, Yarn dapat terus melacak semua paket, pengembang dapat menginstal berbagai hal tanpa mencemari repo mereka, dan kami mempertahankan build yang dapat direproduksi. (Ada juga ruang untuk package.local.json dengan bagian devDependencies , tapi saya tidak yakin itu akan diperlukan.)

  • Orang-orang sudah menggunakan solusi untuk mendapatkan apa yang mereka inginkan, setidaknya tiga di antaranya dijelaskan dalam komentar di atas. Tapi mereka tidak nyaman untuk digunakan, tidak menawarkan jaminan yang sama dan mengharuskan pengembang melawan Yarn untuk mencari tahu. Itu yang terburuk dari kedua dunia.

Saya mungkin melewatkan sesuatu, tapi ini sepertinya percakapan yang berharga.

Saya memiliki kasus penggunaan lain: Saya ingin modul tersedia di REPL tetapi tidak bermaksud menggunakannya dalam kode saya. Seperti berdiri saya perlu masuk ke folder yang berbeda dan menginstal modul itu di sana, kemudian mengimpor beberapa file json menggunakan ../other-project/data/xyz.json .

Tetapi jika saya ingin mengimpor modul dan hal itu mengimpor modul lain menggunakan jalur relatif, itu akan rusak.

Hanya membiarkan saya menginstal modul ke node_modules tanpa menyimpan akan membuat semuanya jauh lebih mudah.

Saya terkejut betapa tahannya para pengelola terhadap gagasan ini.

Ya ampun, saya baru saja membaca komentar sebelumnya dan sikap dari pengelola mengecewakan. Saya mengembangkan banyak plugin khusus kerangka kerja yang memiliki ketergantungan pada pustaka kerangka kerja dan saya ingin menghindari menambahkan itu sebagai ketergantungan keras ke dalam plugin saya.

Saya memiliki plugin yang bergantung pada paket tertentu yang ditentukan dalam peerDependencies , sekarang masalah seperti yang telah dikomentari banyak orang lain adalah, bagaimana Anda menginstal dependensi secara lokal tanpa menambahkannya ke package.json mengajukan? Ya, Anda tidak bisa.

Satu-satunya solusi yang saya temukan adalah menginstal peerDepencies sebagai devDependencies yang tidak terasa ideal sama sekali, tetapi berhasil mengatasi masalah tersebut. Setidaknya npm dalam keadaan yang mengerikan terpasang tanpa mengubah file package.json .

@hpurmann @kittens

Apakah Anda sudah menyerah untuk menanggapi komunitas? Jelas, mengabaikan masalah ini tidak akan menguntungkan Anda dan tidak akan hilang. Apa gunanya menyebut ini proyek open source jika Anda bahkan tidak akan menjawab pertanyaan sederhana jika seseorang melakukan pekerjaan dan mengirimkan PR, apakah Anda akan menerimanya?

Saya mungkin seharusnya menjawabnya beberapa waktu lalu, tepat setelah @viveleroi menjelaskan kasus penggunaannya yang cukup valid (yang tampaknya dimiliki banyak dari Anda). Saat itu saya mengacungkan jempol tanggapannya, yang jelas tidak cukup untuk diperhatikan.

Aku merubah pikiranku. Biasanya, orang menginginkan banyak hal dan jika pengelola menerima setiap fitur, perangkat lunak menjadi membengkak. Saya tidak memiliki kasus penggunaan ini tetapi saya melihat banyak orang menginginkannya.

Aku tidak bisa memutuskan apapun. Saya bukan pengelola proyek ini.

@Vheissu Apa masalah dengan yarn add --peer <dep> ?

bagi saya benang tambahkan - peerberfungsi HINGGA Anda menambahkan paket lain, di mana deps rekan yang ada dihapus dari instalasi lokal dan Anda harus membacanya secara manual.

Saya ingin fitur ini karena hari ini karena saya menulis contoh implementasi perpustakaan saya menggunakan express, tetapi tidak ada kode saya yang bergantung langsung pada express. Saya tidak ingin apa pun untuk diinstal atau bergantung pada Express, tetapi saya ingin menginstalnya ke direktori saya saat ini.

Sama seperti @ brendan-hurley @suyanhanx , saya memiliki dependensi yang ingin saya instal di CI dan bukan secara lokal.
Saya ingin menjaga ketergantungan lokal saya seminimal mungkin sehingga kami tidak perlu membengkak node_modules dan menghabiskan waktu dan ruang kami untuk setiap pengembang yang mengerjakan proyek.

Paket yang dibutuhkan di CI tetapi tidak secara lokal:

  • Alat khusus CI: rilis semantik, greenkeeper-lockfile
  • Alat pelaporan cakupan: codacy-coverage, coverall
  • Alat pelaporan pengujian untuk CI: jest-junit, dll.

Inilah mengapa kami membutuhkan fitur ini:

Menggunakan yarn link tidak akan menautkan dependensi paket, jadi Anda perlu menginstalnya
tujuan yang ditautkan - menambahkan dependensi eksternal ini ke package.json hanya membuatnya sangat tidak nyaman.

Entah yarn link harus menambahkan dependensi atau memberikan cara untuk mengecualikan in tujuan package.json

Saya memiliki kasus penggunaan yang cukup esoteris, tetapi ini akan membantu saya. Saya sepenuhnya memahami mengapa penting untuk yarn.lock dan package.json menjadi sumber kebenaran, dan jika saya menggunakan perintah --no-save , perubahan saya akan terhapus pada yarn berikutnya

Karena itu, saya berharap yarn mempercayai saya untuk mengetahui apa yang saya lakukan dan mengizinkan saya untuk memberikan tanda --no-save . Jika saya mengalami salah satu kasus masalah, saya akan tahu persis apa yang salah, dan bahwa saya sendirilah yang harus disalahkan. :tersenyum:

Kasus penggunaan saya?
Saya menjalankan mesin win 64-bit.
Mesin produksi 32-bit.

Ketergantungan node-sass yang kami miliki hanya mendukung 32-bit kecuali kami memperbarui paketnya.

Tidak mengubah ketergantungan di package.json atau yarn.lock untuk mendukung mesin dev.
Jadi ingin menginstal node-sass terbaru secara lokal untuk mendukung 64-bit, tetapi tidak memengaruhi package.json dan yarn.lock

Saya ingin menginstal @types/* paket ke proyek non-TypeScript tanpa mencemari package.json / yarn.lock untuk pelengkapan otomatis yang lebih baik di VSCode.

Saya menggunakan lerna dengan ruang kerja benang.
Definisi tipe Antd terputus karena pembaruan @ types / [email protected] .
Antd akan memperbaikinya pada akhir pekan.
Tapi sekarang saya perlu memaksa thread untuk menginstal versi tetap dari @ types / [email protected] ke dalam workspaceRoot secara manual tanpa mempengaruhi package.json saat ini (karena ini akan menginstal versi terbaru secara otomatis).

Menjaga perilaku default dari menyimpan ke package.json benar, tetapi ada kasus nyata dimana pengembang harus menginstal modul tanpa mempengaruhi package.json. Terutama ketika ada beberapa perubahan yang tidak terduga dalam beberapa paket.

Memperbarui paket secara implisit dan menyimpan secara implisit ke package.json menyebabkan konflik.

Berikut kasus penggunaan lainnya. Saya mengelola perpustakaan React. Sebelum menerbitkan versi baru, saya ingin menjalankan pengujian terhadap beberapa versi react dan react-dom , untuk memverifikasi bahwa perubahan saya kompatibel ke belakang dan ke depan ( @next ). Saya melakukan ini menggunakan pengaturan di bawah, tetapi sekarang saya ingin menggunakan ruang kerja Yarn jadi saya perlu bermigrasi ke Yarn.

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

Saya tidak dapat membuat skrip ini mengubah package.json karena itu akan membuat perintah terbitkan saya ( pack publish ) gagal karena perubahan yang tidak diatur.

Saya ingin menambahkan paket tambahan di pipeline CI saya untuk tujuan pengujian tanpa menyentuh file package.json (mungkin file mount hanya-baca).
Ini bukan bagian dari komponen dev.
Selama pengembangan dan pengujian pada mesin dev, mereka tidak boleh diinstal dan selama build dan prod mereka tidak boleh diinstal, mereka hanya diperlukan dan dapat diterima di server CI selama pengujian.

Ini bekerja hanya dengan menggunakan npm, tetapi benang harus dapat menghilangkan ketergantungan pada npm.
Ini sangat baik mungkin membawa kita kembali menggunakan npm saja, bukan hanya benang.

Juga itu hanya melanggar janji benang untuk dapat sepenuhnya menggantikan npm, karena itu tidak dapat melakukan apa yang dapat dilakukan oleh npm.

Juga ya benar-benar menyembunyikan fitur ini di belakang beberapa bendera karena ini seharusnya tidak menjadi kasus penggunaan normal tetapi kasus penggunaan tepi.

apa Anda sedang bercanda ? 3 tahun untuk menambahkan saklar sederhana?

Kasus penggunaan lain: Kami menggunakan paket npm ( git-hoooks ) untuk pemeriksaan pra-komit. Tidak semua orang di tim memasang node, jadi menyertakannya di package.json akan merusak komitmen bagi sebagian orang. Jadi saya mencoba membuat skrip npm untuk mengaktifkan / menonaktifkan hook secara sementara dengan menginstal / menghapus git-hooks. Sangat kecewa mengetahui tugas yang tampaknya sederhana & mudah ini hampir tidak mungkin dilakukan dengan benang.

Jika kekhawatirannya adalah bahwa yarn.lock tidak lagi menjadi sumber kebenaran untuk konten node_modules, apa salahnya? Tidak bisakah fungsi yang ada mengabaikan keberadaan dependensi yang tidak terlacak? Yarn adalah alat yang hebat dan pengelola telah melakukan layanan yang hebat untuk komunitas JS, tetapi mereka perlu mempertimbangkan kembali keputusan ini.

apa Anda sedang bercanda ? 3 tahun untuk menambahkan saklar sederhana?

@spanasik dan @Ryuurock : harap sopan saat mendiskusikan perangkat lunak berkualitas tinggi yang disediakan untuk Anda secara gratis.

Ini tidak memakan waktu "3 tahun" karena peralihan ini terlalu rumit untuk diterapkan - ini karena pengelola tetap tidak yakin bahwa ini akan menjadi keuntungan bersih bagi pengguna. Jika Anda tidak setuju dengan ini, buat argumen untuk fiturnya.

@NickHeiner di sini adalah 10 layar argumen. Dan hal utama yang mendorong frustrasi, bukan karena pengelola tidak yakin, tetapi mereka mengabaikannya, tidak membalas argumen, ketika orang "tidak setuju dengan ini, buat argumen untuk fitur tersebut". Dan ketika orang frustasi, tentunya mereka meninggalkan komentar yang tidak menyenangkan. Tolong jangan menyalahkan semuanya pada pengguna.

Saya setuju bahwa akan lebih baik jika pengelola membahas diskusi di sini. Jelas ada minat dari banyak orang selama beberapa tahun. Jadi mungkin saran saya agar @spanasik dan @Ryuurock hanya "membuat argumen" tidak masuk akal, karena kemungkinan besar akan diabaikan seperti yang lainnya di sini.

Dan ketika orang frustasi, tentunya mereka meninggalkan komentar yang tidak menyenangkan. Tolong jangan menyalahkan semuanya pada pengguna.

Saya tidak setuju. Kekasaran ini masih bukan merupakan langkah maju yang berguna, atau perilaku yang dapat diterima di kalangan orang dewasa. Bersikap tidak sopan adalah cara yang bagus untuk membenarkan pengelola mengabaikan ini lebih lanjut: "utas hanyalah troll".

Cara konstruktif untuk maju:

  1. Tarik perhatian pengelola ke utas ini di saluran lain (mungkin mereka telah mengabaikannya) dan minta mereka untuk setidaknya mengakui argumen di sini, bahkan jika mereka tidak setuju.
  2. Garpu / ganti benang dan atur proyek dengan cara yang membuat orang lebih senang.

Trik praktis adalah yarn add --dev pkg && yarn remove pkg . Itu melakukan hal yang sama. Lockfile tetap seperti sebelumnya, begitu tak tersentuh.

Diuji - tidak bekerja.

Kasus penggunaan saya adalah sebagai berikut:
Beberapa paket memiliki tambahan opsional yang dimuat dengan 'require'. Saya tidak ingin menambahkan add-in ini ke bagian devDependencies jadi saya melakukan 'thread add my-add-in' dan menghapusnya secara manual dari file package.json. Pada pipeline CI cloud saya, saya menggunakan 'npm i' menambahkannya (untuk pengujian). Di pipeline lokal saya, saya tidak ingin menggunakan npm karena ini membuat file kunci tambahan. Pilihan terbaik saya sekarang adalah menggunakan npm dan kemudian menghapus file kunci mereka (untuk menghapus kebenaran versi kedua yang muncul).

Jadi setelah membaca semua pertanyaan saya kepada pengelola adalah ini:

  • Mengapa Anda begitu tidak konsisten?
  • Mengapa tidak menerapkan filosofi ini dengan benar di setiap fitur?

    • Yaitu: Putuskan bagaimana sesuatu harus dilakukan untuk kita semua dan hapus semua opsi lain dari semua fitur. Tetap di jalur! Tetap jujur ​​pada diri sendiri!

Fakta yang tidak dapat disangkal adalah bahwa semua perangkat lunak yang baik memiliki pengaturan konfigurasi karena perangkat lunak yang baik akan memungkinkan pengguna untuk memilih yang terbaik untuk situasinya . Dan untuk selalu menyentuh file 'package.json' adalah praktik yang baik - tetapi ada kasus tepi di mana 'benang' tidak cukup untuk tugas karena filosofi ini.

Saya sangat suka benang karena sederhana dan cepat . Sangat disayangkan bahwa pengelola berjuang dalam pertempuran yang pasti akan kalah - karena komunitas terpaksa kembali ke npm yang lambat dan dapat diandalkan untuk membuat semuanya berfungsi.

Mari kita turunkan suhunya sedikit. Tidak ada yang perlu merasa jijik dengan a
perangkat lunak yang boleh mereka gunakan secara gratis.

Pada Rabu, 15 Jan 2020 pukul 23:17 Hajime Yamasaki Vukelic <
[email protected]> menulis:

Saya merasa jijik karena benang membuat saya bekerja dengan cara tertentu. saya suka
memutuskan segala sesuatunya sendiri, dan saya tidak suka ketika alat saya memberi tahu saya bagaimana saya
harus bekerja, menghina kecerdasan saya menjadi masalah terkecil, dan
tidak bisa menyelesaikan sesuatu menjadi yang terbesar.

Untuk percaya pada aturan yang sempurna dan bahwa tidak akan pernah ada kesempatan untuk itu
mematahkan mereka naif. Ada perbedaan antara "praktik terbaik" dan
"lakukan atau mati". Seperti yang dikatakan Oliver Wendell Holmes Sr.

Pria muda itu tahu aturannya, tapi lelaki tua itu tahu pengecualiannya.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43ONORVBW5ZLOQG43
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

Buat pengelola paket Anda sendiri, tidak ada yang memaksa Anda melakukan apa pun.

Tidak marah sama sekali, cukup tunjukkan kesalahan dalam logika Anda:

benang membuatku bekerja dengan cara tertentu.

Benang tidak membuat Anda melakukan apa pun, mereka telah membuat alat (gratis) dan bekerja dengan cara tertentu. Jika Anda tidak menyukainya, gunakan yang lain.

@foxbunny Saya menghargai Anda menjelaskan rasa jijik Anda. :)

Bahkan jika Anda yakin bahwa itu masuk akal dan hanya untuk merasa jijik dalam kasus ini, menurut saya bahasa bukanlah cara yang sopan untuk berbicara dengan orang-orang yang telah membangun alat yang tersedia secara gratis ini untuk Anda. Anda bisa memberikan umpan balik yang membangun sambil tetap bersikap hormat.

@whitolor tim sudah mendapat poin. Pilihan itu --menyimpan itu bodoh. Yarn menjamin kesetimbangan antara node_modules, package.json dan file kunci dan itu bagus. Itu lebih aman .... npm --save berbahaya. Itu mengecewakan saya berkali-kali

Tolong hentikan

Atau bagaimana jika semua orang hanya menggunakan alat yang bekerja dengan cara yang menurut mereka lebih baik dan tenang.

Kasus penggunaan saya adalah

Saya ingin memperbarui sub-ketergantungan aplikasi kita
Saya menghubungkan ketergantungan ini dengan yarn link
Saya kemudian menggunakan yang tertaut di aplikasi kami
Saya menambahkan beberapa ketergantungan di perpustakaan kami
Ketergantungan lib yang ditambahkan tidak dipasang di aplikasi utama setelah yarn install (wtf no.1)
Lalu saya pikir, oke, mari tambahkan dengan cepat tanpa menyimpan ke aplikasi jadi saya bisa memeriksa apakah ada yang berfungsi sebelum saya mempublikasikan pembaruan ke lib kami
Tapi - tidak.

Terima kasih

Maaf melihat komunitas diabaikan oleh penulis.

Sebagai sukarelawan open source, seseorang perlu memiliki filosofi yang koheren atau
proyek akan terurai menjadi bola lumpur. Ini terkadang berarti memberi tahu
orang "tidak". Jika Anda tidak setuju, silakan membuat paket Anda sendiri
manajer, seperti benang diganti npm.

Pada Sel, 3 Mar 2020 di 03:53 Artur Kwiatkowski [email protected]
menulis:

Maaf melihat komunitas diabaikan oleh penulis.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYYY3PNVWWK3TUL52HS4DFVREXG43
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

Saya menggunakan Lerna, dan saya benar-benar hanya ingin menginstal _only_ Lerna di salah satu langkah CI saya, untuk tahap publikasi, karena proyek ini sudah dibangun pada langkah sebelumnya dan artefak telah dipindahkan. Apakah itu skenario yang valid?

^ Komentar asli saya - Sejujurnya saya tidak tahu mengapa saya membutuhkan ini, dan saya tidak tahu utas ini akan meledak begitu parah - tetapi sangat lucu melihat email tentang hal itu bertahun-tahun.

Saya cenderung setuju dengan pengelola di sini:

  1. Saya tidak yakin dengan argumen saya sendiri. Saya kira para pengelola bersikap sopan dengan tidak menyebutnya sebagai argumen yang bodoh.
  2. Bahkan jika seseorang _tidak_ menaikkan PR, itu berarti bahwa pemeliharaan berkelanjutan dari fitur tersebut akan menjadi beban lebih lanjut bagi pengelola, memblokir mereka dari pemeliharaan produk inti.
  3. Fitur semacam ini akan disalahgunakan oleh pemula yang sederhana dan / atau konsumen benang yang relatif tidak terampil, selanjutnya mengabadikan poin 2.

Bagaimanapun, mungkin ada cara yang lebih baik dan lebih berwawasan arsitektur untuk mengurangi kebutuhan akan fitur ini.

Saya membuat yarn-add-no-save untuk mencapai fungsi ini. Ini dapat diinstal secara lokal ke proyek Anda atau secara global:

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

Setelah terinstal, Anda dapat langsung menjalankan:

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

Kasus penggunaan saya adalah menguji modul yang menyatakan peerDependencies sehingga alat memiliki beberapa opsi untuk menginstalnya secara otomatis, untuk melihat semua opsi berjalan:

$yarn add-no-save --help

CATATAN: Saya sadar bahwa menyimpan paket untuk menginstal paket tanpa menyimpannya adalah ironis dan pada dasarnya mengalahkan tujuan, tetapi ini adalah yang terbaik yang dapat saya hasilkan dan itu sesuai dengan kebutuhan saya.

Ini sangat membantu, terutama dukungan peerDeps. Terima kasih.

Ada beberapa argumen bagus untuk fitur ini. Ini tidak seperti melakukannya secara default, orang-orang memintanya untuk berada di belakang bendera yang jelas bahwa hanya orang yang membutuhkannya yang akan menggunakannya. Saat ini, seperti yang lain, saya perlu melakukan beberapa pengujian selama CI dengan versi pustaka lain yang tidak ingin saya simpan . Saya tidak dapat memahami apa yang begitu sulit untuk dipahami di sini.

Saya harus yarn install xxx lalu yarn remove xxx .

Tidak yakin apakah kasus penggunaan ini pernah dibahas. Biarkan saya mencoba menjelaskan situasi saya - Saya memiliki banyak paket yang saling bergantung satu sama lain dalam satu repo. Mereka semua menggunakan dependensi eksternal yang sama dengan paket umum pada sub proyek layanan root di bawahnya, setiap paket lokal perlu dibangun agar dapat dikonsumsi selanjutnya. Saya mencoba menggunakan ruang kerja benang untuk ini. Untuk memulai, saya tidak memiliki paket lokal yang ditentukan di root package.json saya. Setelah satu siklus penuh membangun semua komponen, saya akhirnya memiliki root package.json yang sepenuhnya diperbarui dengan dependensi lokal tersebut. Sekarang ketika yang diperbarui ini dibangun di atas CI- semua paket lokal yang ditambahkan akan gagal karena tidak tersedia. Kami harus menghapus entri yang baru ditambahkan tersebut untuk membuatnya berfungsi di CI.

Saya harus yarn install xxx lalu yarn remove xxx .

sama

Berikut adalah kasus penggunaan karena ingin dapat melakukan ini:

Kami sedang membangun alat dengan ekosistem modular untuk "peralatan" di dalam alat tersebut, dan rencananya adalah untuk instance lokal yang akan disiapkan dengan peralatan tersebut, dan mengaktifkannya secara dinamis melalui konfigurasi. Peralatan diterbitkan ke npm (dan dapat dipanggil di luar kerangka kerja kami jika seseorang menginginkannya).

Proyek vanilla TIDAK bergantung pada paket-paket ini, jadi menyimpan ke package.json tidak pantas. Konfigurasi instance tertentu mungkin meminta salah satu paket untuk diinstal secara lokal.

Kekurangan fitur ini tampaknya menjadi keputusan yang membatasi proyek kami, meskipun kami akan terus mengeksplorasi pendekatan alternatif.

Sebelum saya membaca balasan "pengelola" di sini, saya pikir saya adalah orang yang paling keras kepala.

Hampir 4 tahun ... 🤦

"Keras kepala" tidak sama dengan "memiliki visi desain dan tidak menerapkan semua yang diminta orang".

"Keras kepala" tidak sama dengan "memiliki visi desain dan tidak menerapkan semua yang diminta orang".

Visi desain menggambarkan jalan bahagia, dan pintu keluar seperti yang diminta di sini, menambah kegunaan bagi masyarakat luas.

Mengapa tidak menambahkan bagian ke file kunci yang melacak pemasangan "bentuk bebas", dan cuplikan tambahan dari status quo (dalam node_modules ), untuk membuatnya dapat dibatalkan dengan aman? Atau mungkin letakkan dependensi dalam folder yang terpisah dari node_modules, dan gunakan node_modules hanya untuk menjaga agar tautan tetap terpapar ke paketnya, sehingga Yarn benar-benar dapat mengelola barangnya sendiri dan tidak khawatir tentang pemasangan yang tidak terlihat menimpa dan merusak barang.

Git memecahkan masalah ini beberapa dekade sebelum Anda, kejar! Ciptakan sesuatu! Itulah yang dimaksud dengan desain - menghindari batasan, daripada melawannya (atau menyerah padanya).

Visi terowongan di kedua ujungnya di sini lahir dari ketidaktahuan, pemikiran berlebihan, dan polarisasi yang tidak perlu. Tidak ada seni bela diri atau filosofi atau revolusi atau politik; hanya ada alat, sekumpulan kode, dan pekerjaan yang harus diselesaikan. Jika alat tidak dapat membantu menyelesaikan pekerjaan, itu bukan alat untuk skenario tertentu. Dan untuk alat yang mengaku sebagai alat pengganti untuk keperluan umum, seperti Yarn, ada begitu banyak skenario umum yang diabaikan di sini sehingga alat itu hanya menggali kuburannya sendiri.

Saya merasa seperti semua orang saling mendorong di atas bukit sempit ketika kita bisa mengitarinya.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat