@chinesedfan Sudahkah Anda mencoba yarn upgrade-interactive ?

@milesj Ya, itu menghasilkan hasil yang sama dan saya juga memperbarui langkah-langkah reproduksi dalam deskripsi masalah.

Itu karena yarn add [email protected] menyetel package.json Anda ke _exactly_ versi 1.0.0 seperti yang Anda minta.

yarn upgrade menghormati rentang semver package.json Anda, dan karena Anda menentukan dengan tepat versi 1.0.0, itu tidak akan menawarkan untuk meningkatkan ke versi lain.

Anda dapat menyelesaikan ini dengan beberapa cara:

• yarn upgrade --latest akan mengabaikan rentang semver dan melihat apa yang ditandai sebagai latest di registri.
• ubah package.json untuk menerima rentang versi seperti ^1.0.0 lalu yarn upgrade (Anda mungkin harus yarn install terlebih dahulu untuk memperbarui file kunci untuk rentang yang diubah)
• tentukan versi secara eksplisit ke upgrade , seperti yarn upgrade [email protected] atau yarn upgrade is-alphanumerical@^1.0.0

Sunting:

Maaf, saya baru tahu ada nama paket yang berbeda. alphanumerical dan alphabetical sekilas terlihat sama :)

Benar, karena tidak ada peningkatan untuk is-alphanumerical , pohon dependensi tidak dilintasi lebih dalam untuk menangani dependensi transitifnya.

Anda dapat mencoba menambahkan flag --force dan melihat apakah itu menjadikannya subdependensi. Kalau tidak, saya pikir Anda benar, tidak ada cara mudah untuk melakukannya selain yarn remove is-alphanumerical dan yarn add is-alphanumerical

@rally25rs Terima kasih atas balasan Anda! Saya menguji 2 kasus lagi.

• yarn upgrade is-alphabetical --force juga tidak berfungsi.
• yarn upgrade is-alphanumerical akan memutakhirkan SEMUA subdependensinya meskipun sudah yang terbaru.
  
  
  
  • Tetapi jika saya hanya ingin memutakhirkan subdependensi tertentu, itu masih sangat tidak nyaman.
  
  

ya, ini adalah masalah utama dengan benang saat ini. dan itu sudah dalam diskusi di #2394

duplikat #2394

Tolong, buka kembali: ini bukan duplikat.

2394 menjelaskan duplikasi paket meck-test-bb (ketergantungan tidak langsung):

Saya mendapat dua salinan meck-test-bb

Masalah ini menjelaskan hanya kemampuan untuk meningkatkan ketergantungan tidak langsung (entah bagaimana).

@rally25rs Maafkan saya untuk melakukan ping.

@rally25rs , tolong, Anda telah menutup kedua masalah non-duplikasi, itu salah. Tolong beri kami kemampuan untuk meningkatkan dependensi tidak langsung!

Maaf, ada beberapa kebingungan tentang masalah lainnya. Saya awalnya berpikir 2394 meminta cara untuk memutakhirkan dep transitif menggunakan flag --deep , atau sesuatu seperti itu, jadi saya telah menandai masalah ini sebagai duplikat dari itu. Kemudian setelah membaca ulang 2394 saya pikir ini tentang sesuatu yang berbeda, yang bukan duplikat dari ini seperti yang saya pikirkan sebelumnya.

+1 untuk permintaan fitur ini. Juga contoh untuk siapa pun yang bodoh seperti saya yang perlu memutakhirkan ketergantungan tidak langsung tertentu secara manual untuk sementara:

Mengingat ketergantungan eksplisit jsonwebtoken telah menyelesaikan ketergantungan implisit jws^3.0.0 ke rentan jws=3.1.4 : dan Anda memerlukannya untuk menyelesaikan ke patch 3.1.5 :

Hapus entri jws misalnya di bawah ini dari yarn.lock, dan jalankan kembali yarn . Ketergantungan tidak langsung dan semua paket yang terpengaruh akan diperbarui, tanpa menyentuh hal-hal lain (setidaknya pada yarn v1.3)

jws@^3.0.0, jws@^3.1.4:
  version "3.1.4"
  resolved "https://registry.npmjs.org/jws/-/jws-3.1.4.tgz#f9e8b9338e8a847277d6444b1464f61880e050a2"
  dependencies:
    base64url "^2.0.0"
    jwa "^1.1.4"
    safe-buffer "^5.0.1"

Sunting: Tanda Baca

@alex-thewsey-ibm, terima kasih atas solusinya!

Bekerja pada benang v1.7.

ty, bekerja Benang 1.9.2

Mungkin membantu menyenggol benang dengan ketergantungan selektif resolutions , bahkan jika itu untuk ketergantungan tunggal. Terima kasih kepada @remolueoend untuk petunjuknya!
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

Dari dokumen:

{
  "name": "project",
  "version": "1.0.0",
  "dependencies": {
    "left-pad": "1.0.0",
    "c": "file:../c-1",
    "d2": "file:../d2-1"
  },
  "resolutions": {
    "d2/left-pad": "1.1.1",
    "c/**/left-pad": "1.1.2"
  }
}

Kami memerlukan fitur ini di Autoprefixer untuk menyarankan pengguna cara memperbarui caniuse-lite di yarn.lock mereka https://github.com/postcss/autoprefixer/issues/1184

Masalah yang sama disini. Saya mengharapkan yarn upgrade caniuse-lite browserslist untuk memutakhirkan sub-dependensi. Itu tidak melakukan itu, juga tidak memberi saya pesan kesalahan yang mengatakan bahwa itu tidak dapat memutakhirkannya karena itu bukan ketergantungan.

Menghapus entri lockfile yang relevan dan kemudian menjalankan kembali yarn seperti yang disarankan @alex-thewsey-ibm memperbaiki masalah langsung untuk saya.

Aneh bagi saya bahwa benang tidak memiliki fitur tnis. Saya baru mengenal benang (dan npm), jadi diasumsikan pasti ada cara untuk melakukan ini. Saya masih tidak sepenuhnya yakin apakah ada cara yang tidak jelas untuk melakukan ini yang tidak diketahui oleh siapa pun di utas ini, atau jika memang tidak ada cara untuk melakukan ini.

Jika benar-benar tidak ada cara untuk meningkatkan ketergantungan transitif/tidak langsung di lockfile tanpa menambahkannya ke package.json... Saya tidak mengerti bagaimana pengguna benang melakukannya tanpanya.

Ini adalah perilaku yang tidak terduga IMO - Saya mencoba memperbarui lodash baru-baru ini dengan yarn upgrade [email protected] dan masih belum memperbarui untuk ketergantungan sementara apa pun.

Saya masih memiliki semua major (^4.XX) dan patch (~4.17.X) versi yang menunjuk ke versi lama.

Satu-satunya cara untuk memperbaikinya adalah melalui pengeditan manual yarn.lock dan kemudian mungkin menjalankan yarn upgrade untuk mengkonsolidasikan perubahan. Saya berharap sedikit lebih baik dari alat yang banyak digunakan seperti itu.

Apakah bug atau benang yang diakui ini konservatif secara default dan saya diharapkan untuk mengedit yarn.lock secara manual atau menggunakan beberapa flag?

Saya menduga saya memiliki peringatan keamanan yang sama untuk diselesaikan dengan @Machiaweliczny ;) Akan sangat berguna untuk mengesampingkan ketergantungan tidak langsung sementara kami menunggu proyek untuk memperbaikinya sendiri. Bahkan dengan proyek yang sangat responsif, ada penundaan yang menunggu perbaikan dan rilis.

Memang, ini bermasalah untuk masalah keamanan dalam dependensi tidak langsung, dan solusi pengeditan yarn.lock , meskipun efektif, mengecewakan dan sulit untuk diotomatisasi. Jika ini bukan perilaku default karena alasan tertentu, akan sangat bagus untuk menambahkan opsi seperti --include-indirect yang akan memaksa Yarn untuk mengikuti dependensi tidak langsung.

Saya tidak berpikir itu harus memerlukan opsi, saya tidak mengerti mengapa yarn upgrade [an indirect dependency] tidak hanya memperbarui yarn.lock ke versi terbaru dari ketergantungan tidak langsung yang diizinkan oleh pohon ketergantungan, tanpa perlu pilihan tambahan. Saya pikir sekarang ini hanya no-op?

Namun, solusi lain yang menurut saya menyenangkan adalah menambahkan resolutions ke package.json saya. Jika lodash adalah ketergantungan tidak langsung, dan saya tahu bahwa saya memerlukannya >= 4.7.13 untuk menghindari kerentanan keamanan, saya dapat menambahkan ke package.json saya:

  "resolutions": {
    "lodash": ">= 4.17.13"
  }

Kemudian jalankan yarn install , itu akan memperbarui yarn.lock untuk memenuhi persyaratan itu, atau mengeluh jika tidak bisa karena bertentangan dengan ketergantungan tidak langsung.

Ini sebenarnya tampaknya telah bekerja cukup baik dalam kasus saya; Saya ingin tahu apakah ini bukan "solusi" tetapi solusi yang dimaksudkan? Butuh beberapa saat untuk mengetahuinya. Dan saya tidak memahami banyak hal dengan cukup baik untuk memastikan ini adalah solusi universal/benar atau jika mungkin ada masalah dalam beberapa kasus dengannya. Jika itu adalah solusi 'tepat' untuk meningkatkan dependensi tidak langsung, agak sulit ditemukan.

Mengapa benang tidak menginstal dep transitif yang ingin Anda perbarui tetapi tidak melakukan perubahan package.json, hanya yarn.lock?

Mengapa benang tidak menginstal dep transitif yang ingin Anda perbarui tetapi tidak melakukan perubahan package.json, hanya yarn.lock?

Saya tidak berpikir itu akan (selalu?) Berhasil, karena benang akan dengan senang hati menginstal beberapa versi dari paket yang sama, bahkan jika satu versi akan memenuhi semua rentang semver yang relevan. Jadi ini akan menginstal versi yang Anda inginkan, tetapi tidak menghapus versi yang tidak Anda inginkan.

@djmitche Benar. Anda perlu menginstal versi dalam kisaran yang diharapkan. Tidak ideal dan sedikit membosankan, tetapi tersedia sementara untuk saat ini.

@djmitche Memang, ini bermasalah untuk masalah keamanan dalam dependensi tidak langsung, dan solusi pengeditan yarn.lock , meskipun efektif, mengecewakan dan sulit untuk diotomatisasi.

Ini adalah solusi lain yang sedikit lebih otomatis:

yarn remove is-alphanumerical
yarn add is-alphanumerical

Menggunakan contoh dalam deskripsi PR, ini akan menghapus tingkat atas dep kemudian menambahkannya kembali yang akan mendapatkan semua sub-dep terbaru, sesuai dengan rentang yang ditentukan oleh is-alphanumerical (rentang tanda sisipan, misalnya) . Ini kemudian akan menghasilkan file kunci baru.

Efek sampingnya adalah akan memperbarui semua sub-dep yang tidak ideal. Untuk masalah keamanan di sub-dep A, saya hanya ingin memperbarui sub-dep A.

Solusi menambahkan sub-dep A sebagai dep langsung hanya untuk memperbaiki masalah keamanan lebih buruk karena menimbulkan kebingungan (paket tidak digunakan secara langsung) serta beban pemeliharaan.

penghapusan benang adalah-alfanumerik
penambahan benang adalah alfanumerik

Ini tampaknya menjadi satu-satunya cara yang dapat diandalkan untuk benar-benar memperbarui ketergantungan. Saya menyadari hari ini bahwa kami terjebak pada versi 1.0.0 dari paket yang telah diperbarui ke 1.1.0 setahun yang lalu. Paket yang kami gunakan memang menggunakan ^1.0.0 dan setiap kali kami "mengupgrade" paket itu, paket itu tidak pernah mengambil versi baru 1.1.0 dari ketergantungannya.
Ternyata ada bug yang sangat buruk yang secara diam-diam gagal dalam produk kami yang seharusnya diperbaiki setahun yang lalu tanpa saya membuang waktu untuk menyelidiki mengapa kami mengalami masalah ini.

Saya tidak percaya mengedit yarn.lock secara manual, menghapus lalu menambahkan kembali paket atau menggunakan resolusi selektif adalah "cara" untuk memperbarui ketergantungan tidak langsung.

IMO, yarn upgrade harus memperbarui dependensi tidak langsung ke versi semver terbaru yang diterima, itu sebabnya kami memutakhirkan sebuah paket. Maksud saya, jika ada jeda dalam rentang semver, itu akan memperbarui dependensi tidak langsung, jadi itu harus selalu dilakukan.

Apakah akan membantu untuk menulis semacam skrip eksternal untuk melakukan ini? Saya kira itu hanya akan menghapus semua entri yarn.lock untuk paket yang diberikan, dan kemudian menjalankan kembali benang?

Ada skrip sederhana untuk melakukan ini: https://Gist.github.com/pftg/fa8fe4ca2bb4638fbd19324376487f42

Bisakah salah satu pengelola mengubah label dari cat-feature menjadi cat-bug ?

Bisakah salah satu pengelola mengubah label dari cat-feature menjadi cat-bug?

mengapa? ini bukan bug. Ini seperti yang dirancang. yarn upgrade tidak pernah dimaksudkan untuk digunakan untuk meningkatkan ketergantungan transitif. "Masalah" yang awalnya dibuka bahkan diberi label sebagai permintaan fitur.

Secara internal upgrade menggunakan yarn outdated untuk menentukan apa yang kedaluwarsa dan versi apa yang akan ditingkatkan. outdated hanya memeriksa dependensi langsung.

Saya bisa saja salah, atau mungkin telah berubah, tetapi saya cukup yakin bahwa npm upgrade setidaknya pada 3 tahun yang lalu ketika yarn upgrade terakhir dikerjakan ulang, juga tidak menyediakan cara untuk meng-upgrade dep transitif. (sekali lagi, itu mungkin telah berubah sejak bertahun-tahun, saya tidak terlalu mengetahui perubahan npm).

Siapapun bebas mengirimkan PR untuk menambahkan fungsi ini. Ini adalah proyek sumber terbuka dan terserah kepada masyarakat luas untuk berkontribusi. Permintaan fitur ini telah dibuka selama bertahun-tahun tetapi tidak ada yang melangkah untuk mengimplementasikannya dan itulah mengapa belum "diperbaiki".

@nnmrts bisakah Anda memeriksa skrip saya https://github.com/yarnpkg/yarn/issues/4986#issuecomment -562719589 apakah itu akan membantu Anda untuk saat ini?

@rally25rs Maaf, saya lelah dan pemarah, anggap komentar saya sudah terselesaikan. 😬.

@nnmrts bisakah Anda memeriksa skrip saya #4986 (komentar) apakah itu akan membantu Anda untuk saat ini?

Sayangnya skrip itu tidak berfungsi untuk saya, mencobanya kemarin. Mungkin saya melakukan sesuatu yang salah, tetapi seluruh file yarn.lock saya "dikosongkan" oleh skrip.

Saya tidak yakin seberapa bagus solusi ini, tetapi saya menjalankan skrip yang saya tulis ini:

const fs = require('fs')
const lockfile = require('@yarnpkg/lockfile')
const package = require('./package.json')

const lock = lockfile.parse(fs.readFileSync('yarn.lock', 'utf-8')).object

const allDeps = new Set()

const parseDep = ([name, version]) => {
  allDeps.add(`${name}@${version}`)
}

Object.entries(package.dependencies).forEach(parseDep)
Object.entries(package.devDependencies).forEach(parseDep)

const newLock = Object.fromEntries(Object.entries(lock).filter(([dep]) => allDeps.has(dep)))
const newLockString = lockfile.stringify(newLock)

fs.writeFileSync('yarn.lock', newLockString)

Kemudian jalankan yarn install dan tampaknya menginstal versi terbaru dari dependensi tidak langsung.

Saya berhasil menyelesaikan dependensi dalam/tidak langsung. Aku ingin tahu kapan kita akan mendapatkan dukungan resmi.

https://medium.com/@ayushya/upgrade -javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

Saya telah mencoba untuk menyelesaikan dan menjelaskan risiko pembuatan kembali yarn.lock dan telah menyarankan apa yang harus dilakukan.

Beri tahu saya jika ini berhasil untuk kalian juga. Atau ada saran untuk meningkatkan proses upgrade.

@ayushya Hm, sepertinya berhasil, jenius.

Saya ingin tahu apakah benang akan menerima tambalan di mana yarn upgrade ke ketergantungan tidak langsung (atau perintah lain?) hanya... melakukannya?

@jrochkind Saya akan mengharapkan yarn upgrade dari ketergantungan tidak langsung untuk memutakhirkannya meskipun itu bukan ketergantungan langsung saya. Tanpa fitur itu, Anda bisa ketinggalan bertahun-tahun dalam pembaruan dependensi tidak langsung.

Dalam kasus saya, saya mencoba memutakhirkan fsevents , sehingga tidak memuntahkan kesalahan ketika saya melakukan yarn install (https://github.com/fsevents/fsevents/issues/278 ). fsevents bukan paket yang saya gunakan secara langsung -- itu adalah sesuatu yang webpack-dev-server digunakan. Tapi yang mengejutkan, saya terkunci ke versi apa pun yang ada saat webpack-dev-server pertama kali diinstal di aplikasi ini.

Saya harus menggunakan trik ini untuk memutakhirkannya, yang tampak seperti peretasan total. https://github.com/yarnpkg/yarn/issues/4986#issuecomment -395036563

solusinya tidak bekerja untuk saya, sayangnya, ketergantungan lama yang lama ditambahkan lagi ke file yarn.lock setelah menghapusnya. Saya dapat melihatnya kembali di folder node_modules dan file yarn.lock setelah menjalankan yarn install.

mungkin solusinya tidak kompatibel dengan ruang kerja benang?

@FelipeLujan ketika solusinya berhasil, dependensi dalam masih ditambahkan lagi ke file yarn.lock -- yang diharapkan -- tetapi dengan versi baru yang lebih baru. Tetapi hanya dengan versi baru jika ada versi baru yang dirilis, dan jika diizinkan oleh pohon ketergantungan. Jika beberapa ketergantungan perantara menyatakan batasan yang tidak mengizinkan peningkatan, mereka tetap tidak dapat ditingkatkan. Mereka baru saja ditingkatkan ke yang terbaru yang diizinkan oleh batasan di pohon.

saya tidak menggunakan ruang kerja benang, jadi tidak bisa mengatakan apakah itu relevan.

Ruang kerja benang @FelipeLujan AFAIK bekerja dengan cara yang sama.

Solusi untuk menghapus bagian paket hanya akan meningkatkan versi paket ke versi MINOR/PATCH terbaru.
Jika Anda ingin memutakhirkan Paket ke versi UTAMA yang lebih baru, Anda harus menemukan rantai ketergantungan paket yang menjalankan yarn why package-name-here dan memutakhirkan paket di bagian atas rantainya.

PERHATIAN: Uji kode Anda karena memutakhirkan paket ke versi UTAMA yang lebih baru mungkin membawa beberapa perubahan yang mengganggu.

https://github.com/djmitche/yarn-minify mungkin membantu dengan ini..

Solusi @ayushya bekerja dengan baik untuk saya, secara manual mengedit yarn.lock untuk menghapus ketergantungan tidak langsung, kemudian menjalankan yarn install untuk menambahkannya kembali di versi yang lebih baru.

Bagi saya, ini sepertinya fitur yang harus dibangun ke dalam yarn, daripada mengharuskan Anda untuk mengedit yarn.lock secara manual. Sepertinya cukup mudah untuk membuat fitur yang seolah-olah Anda telah mengedit secara manual untuk menghapus dependensi dan menjalankan yarn install. Saya merasa fitur ini benar-benar harus dibangun menjadi benang, dan saya agak bingung mengapa tidak.

Saya berhasil menyelesaikan dependensi dalam/tidak langsung. Aku ingin tahu kapan kita akan mendapatkan dukungan resmi.

https://medium.com/@ayushya/upgrade -javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

Saya telah mencoba untuk menyelesaikan dan menjelaskan risiko pembuatan kembali yarn.lock dan telah menyarankan apa yang harus dilakukan.

Beri tahu saya jika ini berhasil untuk kalian juga. Atau ada saran untuk meningkatkan proses upgrade.

Saya pikir itu resolusi yang sama yang diberikan oleh @alex-thewsey-ibm. Menghapus ketergantungan tertentu dari yarn.lock membantu saya.
Bagaimanapun, Terima kasih untuk peretasan ini☺️

Menggunakan resolutions di package.json berhasil untuk saya https://github.com/webpack/webpack-dev-server/issues/2739#issuecomment -695164486

Ini setidaknya harus mengembalikan beberapa peringatan:

yarn add [email protected]
yarn upgrade is-alphabetical

Inilah yang saya dapatkan sebagai gantinya:

success Saved lockfile.
success Saved 0 new dependencies.

Tidak ada perubahan pada package.json dan yarn.lock meskipun ada versi paket is-alphabetical baru yang tersedia.