<p>benang mungkin tidak seharusnya paket cache diselesaikan dengan jalur file</p>

Ini membodohi saya juga. Pasti ada cara untuk mengatasi ini tanpa membersihkan semua cache.

Saya pikir mungkin ada tiga cara untuk membuat benang dapat digunakan untuk kasus ini:

1. Saran @donaldpipowitch untuk mengabaikan semua dependensi lokal.
2. Menginstal ulang dependensi lokal jika file di sana dimodifikasi lebih lama daripada saat di-cache. Ini akan mengharuskan kami untuk menyimpan metadata ini. Untuk dependensi lokal kita dapat memasukkan baris seperti ini ke kolom "Diselesaikan": file://<path>@<cache_timestamp>
3. Mengabaikan paket dengan nama paket dengan perintah seperti yarn cache rm <package> dan yarn cache add <package> . Untuk semua dependensi.

Saya ingin saran kedua diimplementasikan. Kecuali, opsi ketiga dapat berguna untuk kasus lain juga. Misalnya, yarn cache add <package> dapat digunakan untuk menyegarkan cache untuk dependensi yang sudah di-cache jika ada yang tidak beres saat mengunduh dependensi.

@hantuzun mengapa cache dependensi lokal sama sekali? mereka lokal, jadi akan cepat terlepas dari cache atau tidak.

@ satya16 Anda benar. Meskipun, saya lebih cenderung ke pendekatan ketiga akan membantu jika ketergantungan dari jaringan dimodifikasi dengan sengaja.

Sesuatu seperti yarn cache ignore <package> akan berguna. Tapi saya pikir mereka tidak harus saling eksklusif. Mengabaikan paket berguna, tetapi membutuhkan pekerjaan manual. Dependensi file dapat dibuat berfungsi tanpa upaya tambahan jika diabaikan secara default.

Adakah yang bisa menjelaskan logika internal saya?

Pemahaman saya:
Ketika sebuah ketergantungan dengan file: ditemukan, file-resolver.js . Dikatakan bahwa ketergantungan harus disalin dan tidak di- hash . Bukankah tidak ada hash berarti itu tidak harus di-cache ...? Tetapi copy-fetcher.js tampaknya menyetel hash ke string kosong alih-alih menyimpan null ... Apakah ini masalah?

@bestander atau @kittens Mungkin Anda bisa menjelaskan lebih lanjut ...? Ingin mendapat sedikit bantuan untuk membuat PR ♥

Hash berarti hash md5 yang digunakan untuk tarball-fetcher, misalnya.
Hash ini kemudian ditambahkan ke file yarn.lock untuk verifikasi di masa mendatang dan juga ditambahkan ke nama folder saat menyimpan folder unzip di cache.
Anda menggali ke arah yang benar, terima kasih telah melihat hal ini, PR sangat disambut baik.
Anda mungkin bisa memulai dengan PR yang menambahkan tes unit yang rusak

Anda mungkin bisa memulai dengan PR yang menambahkan tes unit yang rusak

Oke, terima kasih atas tanggapan Anda. Haruskah saya melakukan ping kepada Anda sebagai reviewer di PR atau haruskah saya melakukan ping ke orang lain (atau bukan siapa-siapa) ...?

Ya, ping aku

@bestander mungkin masalah ini tidak boleh ditutup karena belum diperbaiki?

Ya, itu harus dibuka kembali. Itu ditutup karena saya menulis "perbaikan # 2165" di judul PR saya. Awalnya saya pikir ini akan menjadi PR yang berkelanjutan, tetapi untuk memperbaiki bug ini kami menginginkan dua PR: yang pertama menambahkan tes unit (pernyataan yang akan gagal tidak benar-benar aktif, jadi CI tidak meledak) dan yang kedua benar-benar akan memperbaikinya.

Maaf, github menutup masalah saat PR digabungkan

jadi jelas ini masih menjadi masalah? cukup menjengkelkan untuk berkembang, jujur ​​saja. itu menyebabkan sedikit gangguan bagi saya pada tingkat pribadi di tempat kerja, di mana saya menggunakan file: untuk membuat lingkungan pengembangan modular. bagian yang sial adalah bahwa setiap paket lokal yang saya edit (menggunakan file: path di package.json ), perlu melakukan ini, untuk menarik konten yang diperbarui:

mengedit konten paket eslint-config-base-eslint saya

yarn cache clean && rm -rf node_modules/eslint-config-base-eslint && yarn install --force && yarn lint

Setiap orang dipersilakan untuk berkontribusi pada proyek ini.
Bisa apa saja - mengirimkan tes integrasi yang rusak untuk kasus ini, memperbaiki atau meyakinkan seseorang untuk memperbaiki.
Jika Anda ingin mengobrol tentang cara terbaik untuk mendekati itu, Anda dapat menemukan bantuan di saluran perselisihan.

Saya sebenarnya berpikir bahwa perbaikannya harus 10-15 baris kode, ini mungkin akan menghemat banyak waktu untuk memperbaikinya lebih cepat

FYI: Bisa jadi masalah ini juga relevan untuk langkah linking dependencies lambat. Lihat komentar saya di sini: https://github.com/yarnpkg/yarn/issues/1496#issuecomment -282688818.

Maaf. Saya tidak dapat menemukan waktu untuk membuat PR lain untuk masalah ini :( Saya (dan masih) sangat sibuk.

@bestander Ini adalah pemblokir yang cukup besar bagi saya, mengerjakan proyek multi-modul. Jika saya membaca tautan kode dan komentar hash (bukan null) setiap kali mencoba menyelesaikannya sehingga memaksa instal ulang? Ucapkan UUID atau stempel waktu saat ini? Maafkan saya jika saya melewatkan sesuatu, saya tidak terbiasa dengan cara kerja kode.

Cache baru dengan cap waktu dan uuid terdengar seperti retasan yang masuk akal.
Idealnya kita harus menyalin file secara langsung tanpa cache tetapi mungkin file
perubahan yang lebih kompleks.
Silakan kirim PR

Pada hari Selasa, 7 Mar 2017 pukul 03:38, Matt Traynham [email protected] menulis:

@bestander https://github.com/bestander Ini adalah pemblokir yang cukup besar
bagi saya, mengerjakan proyek multi-modul. Jika saya membaca @donaldpipowitch
https://github.com/donaldpipowitch tautan kode dan komentar
dengan benar, dapatkah kita meminta pemecah file membuat hash baru (sebagai ganti
null) setiap kali mencoba menyelesaikannya sehingga memaksa instal ulang? Ucapkan UUID
atau cap waktu saat ini? Maafkan saya jika saya melewatkan sesuatu, saya tidak terbiasa
dengan cara kerja kodenya.

-
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung, lihat di GitHub
https://github.com/yarnpkg/yarn/issues/2165#issuecomment-284612526 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/ACBdWDS3xSr8KNu1o9Zn8sA9xdO8pyHOks5rjNEmgaJpZM4LFbmf
.

@bestander Mengenai komentar terakhir Anda: Bukankah lebih masuk akal untuk menautkannya dengan symlink, daripada menyalin file? Atau adakah alasan untuk tidak melakukan itu?

@danrot windows sepertinya membutuhkan admin untuk symlink.
juga mengacaukan berulang-ulang untuk menemukan modul node

Symlink juga mengabaikan .npmignore dan hal-hal seperti itu. (Yang saat ini tampaknya juga diabaikan. Yang bisa menjadi masalah: https://github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818)

Apakah ada solusi untuk saat ini melarang pembersihan seluruh cache? Sayangnya sepertinya tidak ada perintah yarn cache rm package kind-of.

@ rhys-e Saya menggunakan skrip kecil ini:

#!/bin/sh
if [ $# != 1 ]
then
   echo Usage $0 package-name
   exit 1
else
    echo Reinstalling $1
fi

dir="node_modules/$1"

if [ -d $dir ]
then
    rm -fr $dir
fi

cache=`yarn cache dir`/npm-${1}*
#        echo $cache
rm -fr $cache && yarn install --force

Adakah yang pernah mencoba yarn link semua dependensi lokal pada postinstall ? Sepertinya solusi yang tepat sampai perbaikan yang tepat mendarat.

Saya kira idenya adalah tidak harus memperbarui nomor versi paket pada setiap perubahan untuk dependensi lokal. Benang link akan memaksa Anda melakukan itu, bukan? (tidak mencoba)

Di sisi saya, apa yang akhirnya saya lakukan adalah memanggil skrip pada fase preInstall yang membandingkan apa yang ada di folder sumber dan folder node_modules untuk dependensi lokal. Jika mendeteksi adanya perbedaan, itu hanya menghapus ketergantungan yang di-cache dan menghapus file integritas (untuk memaksa instal ulang). Jadi, ketika tidak ada perubahan, pemasangan benang cukup cepat (tidak banyak dependensi lokal) dan jika ada versi cache yang sudah ketinggalan zaman tidak digunakan.

Tautan @lucdew pada dasarnya akan membuat symlink di bawah tenda, yang berarti versi lokal terbaru akan digunakan. Tetapi saya pikir memiliki skrip, yang sebelum instalasi membersihkan cache dari departemen tertentu adalah solusi yang tepat sekarang.

Saya telah menguji kombinasi yang berbeda dalam mengatasi perubahan dalam paket lokal yang tidak diperbarui dalam versi terinstal proyek induk di bawah ./node_modules/. Saya menemukan bahwa ini akan dilakukan, tanpa perlu menghapus ./node_modules/pertama:

yarn cache clean; yarn upgrade file:../<package>

Tidak perlu dikatakan, memaksa pembersihan cache global secara manual seharusnya tidak diperlukan untuk memperbarui / meningkatkan paket lokal.

@fungilation Sebagai solusinya, Anda juga dapat menggunakan npm untuk menginstal dependensi lokal dan menghindari kehilangan seluruh cache setiap kali Anda menginginkan pembaruan.

Sesuai # 2860 dan komit penggabungan berikutnya https://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24 , Anda sekarang dapat "menyegarkan" file: dependensi protokol dengan

yarn install --force

Edit Atau tingkatkan paket tertentu (tidak menyadari ini berfungsi juga). Jika versi dependensi tidak berubah, ini tidak mengubah lockfile, tetapi masih akan menyalin versi yang lebih baru.

yarn upgrade [file protocol package name]

Perubahan PR akan membatalkan ketergantungan di cache & menginstalnya kembali secara lokal. yarn install juga akan berfungsi jika versi dependensi berubah, yang membuat file yarn.lock tidak valid. Anda tidak perlu lagi mengosongkan cache, atau menghapus modul dari instalasi lokal.

Itu juga menjadi jelas bagi saya bahwa ada RFC aktif untuk menghubungkan dependensi, mungkin dengan protokol link: . Itu bisa diikuti di sini, https://github.com/yarnpkg/rfcs/pull/34.

@mtraynham Terima kasih atas permintaan tarik Anda! 👌 Ini luar biasa. Ada alasan mengapa --force dibutuhkan? Saat ini saya bahkan tidak tahu apa yang dilakukannya sekarang tanpa mencarinya :) Hanya bertanya, karena npm tidak memerlukan bendera --force dan akan menyenangkan berperilaku seperti npm.

Edit Sepertinya yarn upgrade [dependency] berfungsi. Saya ingin menunjukkan, ini tidak selalu mengubah lockfile, yang seharusnya hanya mencerminkan perubahan versi package.json. Saya telah memperbarui posting asli saya, karena peningkatan mungkin lebih sesuai.

Versi singkatnya adalah, Yarn tidak akan melakukan apapun dengan cache-resolver jika lockfile tidak berubah, jadi kita perlu melewati pemeriksaan lockfile dan menanyakan cache apakah ada versi yang lebih baru. Itu dapat dilakukan dengan menggunakan upgrade atau install --force

Per yarn install --force dokumentasi

"itu mengambil kembali semua paket, bahkan yang telah diinstal sebelumnya".

Ini benar-benar berarti itu akan melewati pemeriksaan integritas file kunci. Pemeriksaan integritas lockfile biasanya akan lolos jika Anda tidak mengubah file package.json dan melakukan bail out dengan baik. Melewati itu meminta cache untuk memeriksa dependensi yang hilang / tidak cocok terhadap lockfile, mendownloadnya jika hilang, dan menyalin kembali dependensi yang lebih baru / hilang secara lokal. Kemudian menjalankan skrip npm install / postInstall .

Perubahan PR sekarang akan membatalkan ketergantungan file: di cache dan menyalin versi baru ke bawah secara lokal. Sebelum ini, itu tidak akan pernah membatalkan ketergantungan file: . Untuk protokol lain, jika Anda tidak mengubah file package.json Anda, mereka tidak akan berubah (di cache dan secara lokal).

Jadi, apa artinya ini bagi kita? Saya memiliki sekitar 60 ketergantungan pada sebuah proyek (mulai dari Angular hingga Webpack), dengan satu ketergantungan file: . Pada install --force , di mana saya hanya ingin menyegarkan ketergantungan lokal, dibutuhkan sekitar ~ 5 detik (naik dari ~ 1,5 detik untuk yarn install ). Bagi saya ini cukup dapat diabaikan, dan saya sebenarnya sangat terkesan dengan betapa sedikit kerja benang yang coba dilakukan di seluruh proses.

Jika ada perintah CLI lain untuk melewati pemeriksaan lockfile dan memeriksa cache hanya untuk ketergantungan file tertentu, itu mungkin akan lebih cepat, tetapi saya belum menemukannya.

Semua yang dikatakan, saya masih menyebut ini sebagai plester. Ini dapat diganti dengan solusi yang lebih baik seperti link: ; Saya tidak berpikir ada orang yang benar-benar peduli untuk menyimpan ketergantungan lokal. Paling tidak, biaya tambahan menggunakan install --force atau upgrade sebagian besar lalai dan Anda tidak lagi harus yarn cache clean; mv node_modules /tmp/ .

Jawaban yang bagus. 👏 Terima kasih telah menuliskan ini.

Apakah benang menimpa file proyek symlink lokal dengan file dari cache benang? (karena sepertinya itulah yang terjadi)

Perubahan PR sekarang akan membatalkan file: ketergantungan pada cache dan menyalin versi baru ke bawah secara lokal.

Apakah ini berarti bahwa setiap kali saya memanggil $ yarn di dalam paket yang memiliki "foo": "file:../" sebagai ketergantungan salinan baru "file:../" akan dibuat?

Misalnya saya memiliki paket dengan banyak contoh yang juga merupakan paket:

foo/
foo/examples/
foo/examples/example-1/
foo/examples/example-2/
foo/examples/example-3/
...
foo/examples/example-10/

Dan sepertinya saya memiliki foo 10 kali sekarang di cache benang. Saya juga menguji contoh saya pada setiap perubahan versi foo (dan saya memiliki beberapa modul yang dikonfigurasi dengan cara itu, bukan hanya foo ) sehingga sepertinya cache benang saya tumbuh _really_ cepat saat ini.

Apakah ini perilaku yang benar?

Saya pikir ini adalah alternatif yang lebih baik daripada memiliki versi lama di cache Anda.
Dengan benang 0.26 Anda dapat menggunakan link: untuk membuat symlink daripada menyalin file.
Kami juga sedang mengerjakan ruang kerja yang akan mengotomatiskan pembuatan symlink, https://github.com/yarnpkg/yarn/issues/3294

Ya, menantikan ruang kerja 👍

link: belum berfungsi dengan npm, bukan? (Karena https://github.com/npm/npm/pull/15900 masih terbuka.)

Dari npm 5 patchnote , file sekarang secara otomatis dihubungkan dengan sintaks file: :

npm install ./packages/subdir sekarang akan membuat symlink daripada instalasi biasa. file: //path/to/tarball.tgz tidak akan berubah - hanya direktori yang terhubung. (# 15900)

Jadi ya, tidak ada link dengan npm.

npm install ./packages/subdir sekarang akan membuat symlink daripada instalasi biasa

Agak disayangkan. Deps file tidak pernah berperilaku sama karena menyalin semuanya (termasuk node_modules ) dan tidak menghormati bidang .npmignore atau files . Sekarang lebih buruk dengan symlink.

Saya pikir file: dan link: dapat ditingkatkan lebih lanjut, ada berbagai strategi yang memiliki PRO dan CON mereka sendiri dan Yarn harus memungkinkan orang untuk memilih satu.
Misalnya knit RFC dapat diimplementasikan sebagai salah satu strategi https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md

@bestander

Saya pikir ini adalah alternatif yang lebih baik daripada memiliki versi lama di cache Anda.

Atau begitulah Anda akan percaya sampai Anda kehabisan ruang disk dan menemukan bahwa cache Yarn Anda menggunakan puluhan gigabyte untuk jutaan file yang sama sekali tidak berguna .
IMO yang membuat semuanya lebih serius rusak daripada sebelumnya, karena Anda hanya mengetahui setelah Anda merusak sementara sistem pengembangan Anda.

Hai teman-teman, ada pembaruan tentang masalah ini? Ini benar-benar masalah besar bagi kami, terutama saat kami mengerjakan beberapa produk sekaligus yang bergantung pada multi-dependensi terkait yang sama. Gigabyte cache dalam satu hari pengembangan, dll. Bisakah Anda setidaknya menjadikannya opsional dan menonaktifkan cache untuk paket semacam itu?

@nikdojo Gunakan benang link: protokol untuk dependensi daripada file: , ini menggunakan symlink. Itu diperkenalkan di 0,26 .

Alternatifnya, mulai gunakan ruang kerja jika Anda memiliki banyak dependensi antar-proyek.

@mtraynham Thx untuk petunjuknya, saya mencoba menemukan info apa pun tentang link: protokol di dokumen resmi, tetapi sepertinya tidak ada. Bereksperimen dengan ruang kerja sekarang.

@bestander btw seperti yang Anda tahu, react-native tidak mendukung symlink, jadi jika kami bekerja dengan rn libs, itu masih menjadi masalah besar.

Ini tidak pernah terpecahkan, bukan? Anda harus menggunakan linklocal (paket NPM) untuk menghubungkan paket lokal (yang seharusnya menjadi cara standar benang beroperasi saat menggunakan paket dari sistem file lokal - menggunakan junctions atau symlink pada Windows daripada caching). yarn install kemudian menimpa semuanya dengan hal-hal lama dari cache dan Anda harus mulai menautkan lagi.

Bisakah kita menjadi astronot arsitektur yang lebih sedikit dan tidak menyimpan paket lokal dalam cache? Masalah ini sekarang berusia 1,5 tahun, dan saya bosan menjalankan yarn add ../<another-local-package> setiap kali saya mengubah sesuatu di another-local-package .

Hai @filasi
Saya telah membuka masalah terkait lainnya: # 6037

tidak bekerja
Saya sudah memasukkan file App.js
console.log ('here we are'), dan tidak menghasilkan.
kemudian hapus semua file dan itu masih membuat output dari cache.
Bagaimana cara menghindarinya?

Benang benar-benar mengecewakan saya dalam masalah ini. Itu bagus untuk yang lainnya, kecuali untuk ini.

Saya telah mencoba menginstal versi baru dari paket lokal untuk tujuan pengujian, dan saya tetap menggunakan paket lama apa pun yang saya lakukan.

Saya sudah mencoba:

1. Membersihkan cache benang ( yarn cache clean package-name )
2. yarn add dengan --force
3. Menghapus node_modules/package-name dan yarn add ing lagi
4. Memperbarui nomor versi dan nama file dari paket lokal ( benang masih menginstal konten versi lama , meskipun dilaporkan menginstal yang lebih baru)
5. Kombinasi dari semua hal di atas

Ini konyol, dan saya telah menghabiskan hampir 4 jam hari saya untuk ini.

Kami membutuhkan kemampuan untuk mengembangkan dan menginstal ulang paket lokal . Saya mengandalkan benang untuk menginstal file di folder .bin, jadi yarn link tidak mungkin.

@ Yarn Developers: Apakah Anda dapat menginstal paket lokal, membuat perubahan pada paket lokal tersebut, dan kemudian mendapatkan perubahan untuk diterapkan dengan menginstal lagi?

@gregjacobs Saya sukses dengan yarn install --force

@jonathantorley Saya baru saja mencobanya lagi dengan --force dan masih tidak berhasil dengan benang 1.12.3

Untuk orang lain yang menghadapi masalah ini: satu solusi yang saya gunakan agar ini benar-benar berfungsi adalah meningkatkan nomor versi paket dependen. Agak mengganggu, dan Anda harus ingat untuk melakukannya pada setiap perubahan (kecuali jika Anda dapat membuat skrip).

yarn seharusnya tidak memerlukan solusi ini saat menginstal paket lokal

Saya menambahkan yarn upgrade MY_PACKAGE_NAME dalam preinstall skrip, dan itu meningkatkan ke versi NPM terbaru dengan baik. (Namun, saya perlu meningkatkan versi NPM secara manual).

Tampaknya yarn add file:PATH sekarang selalu meningkatkan konten baru sekarang di benang 1.13.0.
yarn install masih belum.

@leavter Masih tidak untuk saya.

Saya harus mengganti nama tgz agar bisa diperbarui

Coba gunakan perintah link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn add file:PATH tidak meningkatkan konten baru untuk saya. Selain itu, file dalam package.json dan .npmignore tidak dihormati.

Ini berfungsi jika Anda mengubah versi paket Anda.

Jika Anda ingin yarn add file:PATH untuk menghormati file di package.json dan .npmignore, Anda harus menjalankan yarn pack dalam ketergantungan paket lokal Anda dan kemudian di mana Anda ingin menginstalnya jalankan yarn add file:path-to-local-pacckage.tgz

Coba gunakan perintah link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn link tidak dimaksudkan untuk menjawab masalah yang sama. Tidak baik jika seseorang menginginkan paket npm seperti jika itu diterbitkan dengan menghormati file di package.json dan .npmignore

@leavter Masih tidak untuk saya.

Saya harus mengganti nama tgz agar bisa diperbarui

Saya tidak memiliki tgz dalam paket saya yang saya gunakan yarn add file: PACKAGE_PAH untuk menambahkannya dalam proyek saat ini. Saya hanya memiliki kode js di paket saya. Mungkin tgz masih salah?

tidak bekerja untukku juga

@bestander mengapa masalah ini ditutup? Benang masih menyimpan file lokal dan paket tgz. Ruang kerja bukanlah solusi dalam beberapa kasus, misalnya jika satu paket memiliki deps dengan versi tertentu, dan paket lain memiliki devDeps paket yang sama seperti yang pertama, tetapi dengan versi lain, dan jika Anda menautkan satu paket ke paket lain, proyek Anda telah rusak .

Saya memiliki masalah yang sama dengan @gregjacobs. yarn cache clean package tidak membantu. Tetapi saya menemukan bahwa jika Anda menginstal yarn add path/to/package.tgz dan kemudian mengganti arsip ke yang lain, Anda dapat menginstal versi baru cukup ubah jalur seperti yarn add path/to/../to/package.tgz , jadi jalur absolutnya sama, tetapi untuk utasnya berbeda .

Saya tidak mengerti di mana lagi paket cache toko benang dengan jalur resolusi, bahkan yarn cache list --pattern package kosong.

Saya pikir masalahnya ada di sini https://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58 -L63

Apa yang terjadi:

• Dari url path/to/package.tgz menghasilkan hash (itulah mengapa path/to/package.tgz dan path/to/../to/package.tgz menghasilkan hash yang berbeda)
• Dengan hash itu membuat direktori temp untuk paket (seperti ini /Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 )
• Untuk menjalankan pertama isValidModuleDest kembali false dan semuanya berjalan dengan baik
• Paket tarball diekstrak di direktori ini
• File dari direktori itu dipasang ke proyek
• Anda memodifikasi mengembangkan sumber proyek dan membangun / mengemas paket tarball baru dengan nama dan lokasi yang sama dengan yang sebelumnya
• Dan Anda mencoba menginstal tarball baru, tetapi hash yang dihasilkan sama seperti sebelumnya dan direktori temp tidak dihapus setelah dijalankan pertama kali
• Jadi saat ini isValidModuleDest return true
• Dan benang menginstal versi lama dari paket Anda
• Anda menjalankan yarn cache clean package , tetapi direktori temp tetap tidak tersentuh

@bestander, bisakah kita menghapus direktori temp di sini https://github.com/yarnpkg/yarn/blob/master/src/config.js#L431 ?

Menghadapi masalah yang sama, cache di bawah folder temp memakan waktu 10GB setelah saya mengerjakan pacakge lokal saya hanya untuk satu hari!

Bisakah kita membuka kembali masalah ini? Kami menghadapi masalah yang sama. Dua proyek yang mereferensikan paket lain melalui file:. Setelah beberapa build di server CI / CD kami, folder cache mulai menempati banyak ruang.

Saya pikir protokol tautan adalah perbaikan terbaik untuk ini, file: // tidak berfungsi karena masih membutuhkan cache yang bersih secara manual & pemasangan paksa

https://github.com/yarnpkg/yarn/issues/2165#issuecomment -345825904

buat saja ketergantungan Anda seperti ini

"<package>": "link:./libs/<package>"

@alxtz Apakah protokol tautan berfungsi dengan paket di tgz?

Saya pikir protokol tautan adalah perbaikan terbaik untuk ini, file: // tidak berfungsi karena masih membutuhkan cache yang bersih secara manual & pemasangan paksa

# 2165 (komentar)

buat saja ketergantungan Anda seperti ini

"<package>": "link:./libs/<package>"

Terima kasih untuk ini mereplikasi perilaku NPM yang akan menghubungkan referensi file:.. di node_modules . Tampaknya tidak didokumentasikan, setidaknya tidak di sini di mana saya akan menemukannya: https://yarnpkg.com/lang/en/docs/package-json/

Sayangnya, link tidak dapat digunakan di semua kasus.

Misalnya, saya memerlukan ketergantungan bersama / rekan dari paket SDK saya, yang ketika saya membuat perubahan, saya akan menautkan untuk pekerjaan pengembang lokal.
Dengan link , yarn tidak menyadari bahwa dependensi adalah dependensi bersama / peer dan menggunakan paket lokal di mana symlink berada, yang salah.

Saya telah menggunakan yarn pack bersama yarn add file:<path_to_packed_tgz> untuk menyiasati ini.
Sementara saya dapat terus mengganti nama paket setiap kali saya mengemasnya dan menempelkannya ke repo saya, agar tidak menghasilkan hash yang sama, sesuai dengan temuan fantastis

Saya mem-fork repo dan meletakkan klausa ekstra di pernyataan if untuk menghentikan thread agar tidak pernah memuat paket .tgz lokal dari cache jika ditentukan menggunakan yarn add file:<path> .

const dest = this.config.getTemp(crypto.hash(url));
// If specified using file: never load from cache
if (!url.match(/file:/) && (await this.config.isValidModuleDest(dest))) {
  // load from local cache
} else {
  // continue as if it's a new package
}

Saya dapat membuat PR jika orang-orang menginginkannya, meskipun saya belum pernah melakukannya sebelumnya dan ini perbaikan yang cukup rumit.
Bisakah seseorang mengkonfirmasi apakah pendekatan ini akan terus menambahkan paket lokal ke cache benang atau tidak?

@ojboj untuk saat ini, yalc mungkin bisa membantu sampai ini diperbaiki. Telah bekerja sangat baik bagi saya untuk menguji paket secara lokal sebelum diterbitkan.

@souporserious Itulah yang saya butuhkan / inginkan, terima kasih banyak!

Gila ini masih menjadi masalah setelah bertahun-tahun.

Apakah itu diperbaiki di [email protected]?

@wKich Saya yakin begitu! Saya belum mengujinya secara pribadi, tetapi sepertinya mereka menyelesaikan pengembangan lokal melalui protokol portal baru.

Saya masih mendapatkan kesalahan "membongkar di tujuan yang sama" menggunakan protokol link: , dan itu mereferensikan direktori cache saya, jadi menurut saya benang masih menyimpan ketergantungan link: . Saya mereferensikan 2 salinan dari paket lokal yang sama, disalin ke folder .deps/ dari setiap aplikasi yang menggunakannya - front-end dan renderer dalam kesalahan di bawah ini. (Tidak dapat menautkan ke aslinya karena alasan yang tidak terkait)

warning Pattern ["@horizon/common<strong i="11">@link</strong>:packages/front-end/.deps/@horizon/common"] is trying to unpack in the same destination "/home/garyo/.cache/yarn/v6/[email protected]/node_modules/@horizon/common" as pattern ["@horizon/common<strong i="12">@link</strong>:packages/renderer/.deps/@horizon/common"]. This could result in non-deterministic behavior, skipping.