@chinesedfan क्या आपने yarn upgrade-interactive की कोशिश की है?

@milesj हां, यह एक ही परिणाम में परिणत होता है और मैंने समस्या विवरण में पुन: पेश चरणों को भी अपडेट किया है।

ऐसा इसलिए है क्योंकि आपके अनुरोध के अनुसार yarn add [email protected] आपके package.json को _exactly_ संस्करण 1.0.0 पर सेट करता है।

yarn upgrade आपके package.json सेवर रेंज का सम्मान करता है, और चूंकि आपने बिल्कुल संस्करण 1.0.0 निर्दिष्ट किया है, इसलिए यह अन्य संस्करणों में अपग्रेड करने की पेशकश नहीं करेगा।

आप इसे दो तरीकों से हल कर सकते हैं:

• yarn upgrade --latest सेवर रेंज को नजरअंदाज कर देगा और देखें कि रजिस्ट्री में latest के रूप में क्या टैग किया गया है।
• ^1.0.0 फिर yarn upgrade जैसी संस्करण श्रेणी को स्वीकार करने के लिए package.json बदलें (बदली गई सीमा के लिए लॉक फ़ाइल को अपडेट करने के लिए आपको इसे प्राप्त करने के लिए पहले yarn install की आवश्यकता हो सकती है)
• upgrade के लिए स्पष्ट रूप से एक संस्करण निर्दिष्ट करें, जैसे yarn upgrade [email protected] या yarn upgrade is-alphanumerical@^1.0.0

संपादित करें:

क्षमा करें, मैंने अभी-अभी देखा है कि विभिन्न पैकेज नाम हैं। alphanumerical और alphabetical एक नज़र में एक जैसे दिखते हैं :)

ठीक है, चूंकि is-alphanumerical के लिए कोई अपग्रेड नहीं है, इसलिए डिपेंडेंसी ट्री अपनी सकर्मक निर्भरता को संभालने के लिए किसी भी गहराई तक नहीं जाता है।

आप --force ध्वज जोड़ने का प्रयास कर सकते हैं और देख सकते हैं कि यह उप-निर्भरता बनाता है या नहीं। अन्यथा मुझे लगता है कि आप सही हैं, yarn remove is-alphanumerical और yarn add is-alphanumerical के अलावा ऐसा करने का कोई आसान तरीका नहीं है

@rally25rs आपके उत्तर के लिए धन्यवाद! मैंने 2 और मामलों का परीक्षण किया।

• yarn upgrade is-alphabetical --force भी काम नहीं करता।
• yarn upgrade is-alphanumerical अपनी सभी उप-निर्भरता को अपग्रेड करेगा, भले ही वह पहले से नवीनतम हो।
  
  
  
  • लेकिन अगर मैं सिर्फ एक निर्दिष्ट उप-निर्भरता को अपग्रेड करना चाहता हूं, तो यह अभी भी बहुत सुविधाजनक नहीं है।
  
  

हाँ, इस समय यार्न के साथ यह एक बड़ी समस्या है। और यह पहले से ही #2394 . पर चर्चा में है

डुप्लिकेट #2394

कृपया, फिर से खोलें: यह डुप्लिकेट नहीं है।

2394 meck-test-bb पैकेज (अप्रत्यक्ष निर्भरता) के दोहराव का वर्णन करता है:

मुझे मेक-टेस्ट-बीबी . की दो प्रतियां मिलीं

यह समस्या अप्रत्यक्ष निर्भरता (किसी तरह) को अपग्रेड करने की क्षमता का वर्णन करती है।

@rally25rs मुझे पिंग करने के लिए क्षमा करें।

@rally25rs , कृपया, आपने दोनों गैर-डुप्लिकेटिंग मुद्दों को बंद कर दिया है, यह गलत है। कृपया हमें अप्रत्यक्ष निर्भरता को अपग्रेड करने की क्षमता दें!

क्षमा करें, दूसरे मुद्दे पर कुछ भ्रम था। मैंने मूल रूप से सोचा था कि 2394 एक --deep ध्वज, या ऐसा कुछ का उपयोग करके एक ट्रांजिटिव डिपो को अपग्रेड करने का तरीका पूछ रहा था, इसलिए मैंने इस मुद्दे को उसी के डुप्लिकेट के रूप में चिह्नित किया था। बाद में 2394 को फिर से पढ़ने के बाद मुझे लगता है कि यह कुछ अलग था, जो इस तरह का डुप्लिकेट नहीं है जैसा मैंने मूल रूप से सोचा था।

इस सुविधा अनुरोध के लिए +1। मेरे जैसे गूंगा किसी के लिए भी एक उदाहरण, जिसे अंतरिम में मैन्युअल रूप से एक विशिष्ट अप्रत्यक्ष निर्भरता को अपग्रेड करने की आवश्यकता है:

स्पष्ट निर्भरता को देखते हुए jsonwebtoken ने अंतर्निहित निर्भरता jws^3.0.0 को कमजोर jws=3.1.4 पर हल कर दिया है: और आपको इसके बजाय पैच किए गए 3.1.5 को हल करने की आवश्यकता है:

jws प्रविष्टि को हटाएं जैसे कि नीचे यार्न.लॉक से, और फिर से चलाएं 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"

संपादित करें: विराम चिह्न

@ एलेक्स-थ्यूसी-आईबीएम, कामकाज के लिए धन्यवाद!

यार्न v1.7 पर काम किया।

ty, काम किया यार्न 1.9.2

चुनिंदा निर्भरता के साथ यार्न को कुहनी मारने में मदद मिल सकती है resolutions , भले ही यह एकल निर्भरता के लिए हो। संकेत के लिए @remolueoend को धन्यवाद!
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

डॉक्स से:

{
  "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"
  }
}

उपयोगकर्ताओं को अपने yarn.lock https://github.com/postcss/autoprefixer/issues/1184 में caniuse-lite को अपडेट करने का सुझाव देने के लिए हमें Autoprefixer में इस सुविधा की आवश्यकता है।

वही समस्या है। मुझे उप-निर्भरता को अपग्रेड करने के लिए yarn upgrade caniuse-lite browserslist की उम्मीद थी। इसने ऐसा नहीं किया, न ही इसने मुझे यह कहते हुए एक त्रुटि संदेश दिया कि यह इसे b/c अपग्रेड नहीं कर सकता है, यह निर्भरता नहीं है।

प्रासंगिक लॉकफाइल प्रविष्टियों को हटाना और फिर yarn को फिर से चलाना जैसा कि @alex-thewsey-ibm ने सुझाव दिया कि मेरे लिए तत्काल समस्या ठीक हो गई है।

यह मेरे लिए अजीब है कि यार्न में टीएनआईएस विशेषता नहीं है। मैं यार्न (और एनपीएम) के लिए नया हूं, इसलिए माना जाता है कि ऐसा करने का एक तरीका होना चाहिए। मुझे अभी भी पूरी तरह से यकीन नहीं है कि ऐसा करने का कोई स्पष्ट तरीका है कि इस धागे में कोई भी नहीं जानता है, या अगर ऐसा करने का कोई तरीका नहीं है।

अगर लॉकफाइल में एक ट्रांजिटिव/अप्रत्यक्ष निर्भरता को package.json में जोड़े बिना अपग्रेड करने का कोई तरीका नहीं है ... मुझे समझ में नहीं आता कि यार्न उपयोगकर्ता इसके बिना कैसे करते हैं।

यह अप्रत्याशित व्यवहार आईएमओ है - मैंने हाल ही में yarn upgrade [email protected] के साथ लॉश को अपडेट करने का प्रयास किया और यह अभी भी किसी क्षणिक निर्भरता के लिए अपडेट नहीं हुआ है।

मेरे पास अभी भी सभी major (^4.XX) और patch (~4.17.X) संस्करणों के साथ पुराने संस्करण की ओर इशारा किया गया था।

इसे ठीक करने का एकमात्र तरीका yarn.lock के मैन्युअल संपादन और फिर परिवर्तनों को समेकित करने के लिए yarn upgrade चलाना है। मैं इस तरह के व्यापक रूप से उपयोग किए जाने वाले टूल से थोड़ा बेहतर होने की उम्मीद करूंगा।

क्या यह स्वीकृत बग या यार्न डिफ़ॉल्ट रूप से रूढ़िवादी है और मुझे मैन्युअल रूप से yarn.lock संपादित करने या कुछ ध्वज का उपयोग करने की उम्मीद है?

मुझे संदेह है कि मेरे पास @Machiaweliczny के रूप में हल करने के लिए एक ही सुरक्षा चेतावनी है;) अप्रत्यक्ष निर्भरता को ओवरराइड करना वास्तव में उपयोगी होगा जब हम परियोजनाओं पर स्वयं को ठीक करने के लिए प्रतीक्षा करते हैं। यहां तक ​​​​कि अत्यधिक प्रतिक्रियाशील परियोजनाओं के साथ सुधार और रिलीज की प्रतीक्षा में देरी हो रही है।

वास्तव में, यह अप्रत्यक्ष निर्भरता में सुरक्षा मुद्दों के लिए समस्याग्रस्त है, और संपादन का समाधान yarn.lock प्रभावी होने पर, निराशाजनक और स्वचालित करना मुश्किल है। अगर यह किसी कारण से डिफ़ॉल्ट व्यवहार नहीं है, तो --include-indirect जैसे विकल्प को जोड़ना बहुत अच्छा होगा जो यार्न को अप्रत्यक्ष निर्भरताओं का पालन करने के लिए मजबूर करेगा।

मुझे नहीं लगता कि इसे एक विकल्प की आवश्यकता होनी चाहिए, मुझे नहीं लगता कि yarn upgrade [an indirect dependency] सिर्फ यार्न को अपडेट क्यों नहीं करता है। अप्रत्यक्ष निर्भरता के नवीनतम संस्करण में लॉक करें जिसे निर्भरता पेड़ द्वारा अनुमति दी जाती है, बिना किसी आवश्यकता के अतिरिक्त विकल्प। मुझे लगता है कि अभी यह सिर्फ एक नो-ऑप है?

हालांकि, एक और समाधान जो मैंने पाया कि मैं खुश हूं, वह है resolutions को अपने package.json में जोड़ना। यदि lodash एक अप्रत्यक्ष निर्भरता है, और मुझे पता है कि सुरक्षा भेद्यता से बचने के लिए मुझे इसकी आवश्यकता>= 4.7.13 होनी चाहिए, तो मैं अपने package.json में जोड़ सकता हूं:

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

फिर बस yarn install चलाएं, यह उस आवश्यकता को पूरा करने के लिए yarn.lock को अपडेट करेगा, या शिकायत नहीं कर सकता है क्योंकि यह अप्रत्यक्ष निर्भरता के साथ संघर्ष करता है।

ऐसा लगता है कि वास्तव में मेरे मामले में बहुत अच्छा काम किया है; मुझे आश्चर्य है कि क्या यह "समाधान" नहीं बल्कि इच्छित समाधान है? हालांकि मुझे यह पता लगाने में थोड़ा समय लगा। और मैं यह सुनिश्चित करने के लिए चीजों को अच्छी तरह से नहीं समझता कि यह एक सार्वभौमिक/सही समाधान है या यदि इसके साथ कुछ मामलों में कोई समस्या हो सकती है। यदि यह अप्रत्यक्ष निर्भरता के उन्नयन के लिए 'सही' समाधान है, तो इसे खोजना कुछ कठिन था।

आप जिस ट्रांजिटिव डिपो को अपडेट करना चाहते हैं, उसे यार्न क्यों नहीं स्थापित करते हैं, लेकिन पैकेज के लिए प्रतिबद्ध नहीं हैं। जेसन परिवर्तन, बस यार्न। लॉक?

आप जिस ट्रांजिटिव डिपो को अपडेट करना चाहते हैं, उसे यार्न क्यों नहीं स्थापित करते हैं, लेकिन पैकेज के लिए प्रतिबद्ध नहीं हैं। जेसन परिवर्तन, बस यार्न। लॉक?

मुझे नहीं लगता कि यह (हमेशा?) काम करेगा, क्योंकि यार्न खुशी से एक ही पैकेज के कई संस्करण स्थापित करेगा, भले ही एक संस्करण सभी प्रासंगिक सेवर श्रेणियों को संतुष्ट करेगा। तो यह आपके इच्छित संस्करण को स्थापित करेगा, लेकिन उस संस्करण को नहीं हटाएगा जो आप नहीं चाहते हैं।

@djmitche राइट। आपको अपेक्षित सीमा के भीतर संस्करण स्थापित करना होगा। आदर्श नहीं और थोड़ा थकाऊ, लेकिन अभी के लिए उपलब्ध स्टॉपगैप।

@djmitche वास्तव में, यह अप्रत्यक्ष निर्भरता में सुरक्षा मुद्दों के लिए समस्याग्रस्त है, और संपादन का समाधान yarn.lock , जबकि प्रभावी, निराशाजनक और स्वचालित करना मुश्किल है।

यह एक और समाधान है जो थोड़ा अधिक स्वचालित है:

yarn remove is-alphanumerical
yarn add is-alphanumerical

पीआर विवरण में उदाहरण का उपयोग करते हुए, यह शीर्ष स्तर के डिपो को हटा देगा और फिर इसे फिर से जोड़ देगा, जो is-alphanumerical (उदाहरण के लिए कैरेट रेंज) द्वारा निर्दिष्ट श्रेणियों के अनुसार, इसके सभी नवीनतम उप-डिप्स प्राप्त करेगा। . इसके बाद यह एक नई लॉक फाइल तैयार करेगा।

इसका दुष्परिणाम यह है कि यह सभी सब-डिप्स को अपडेट कर देगा जो कि आदर्श नहीं है। सब-डिप ए में सुरक्षा समस्या के लिए मैं केवल सब-डिप ए को अपडेट करना चाहता हूं।

सुरक्षा समस्या को ठीक करने के लिए सब-डिप ए को प्रत्यक्ष डिपो के रूप में जोड़ने का समाधान बदतर है क्योंकि यह भ्रम पैदा करता है (पैकेज का सीधे उपयोग नहीं किया जाता है) और साथ ही रखरखाव का बोझ भी।

यार्न रिमूव है-अल्फ़ान्यूमेरिकल
यार्न ऐड है-अल्फ़ान्यूमेरिकल

यह वास्तव में एक निर्भरता को अद्यतन करने का एकमात्र विश्वसनीय तरीका प्रतीत होता है। मुझे आज एहसास हुआ कि हम एक पैकेज के 1.0.0 संस्करण पर अटके हुए थे जो एक साल पहले 1.1.0 में अपडेट हो गया था। हम जिस पैकेज का उपयोग कर रहे थे, उसने ^1.0.0 का उपयोग किया और हर बार हमने उस पैकेज को "अपग्रेड" किया, जिसने कभी भी अपनी निर्भरता के नए 1.1.0 संस्करण को नहीं उठाया।
पता चला कि एक बहुत खराब बग था जो हमारे उत्पाद में चुपचाप विफल हो रहा था जिसे एक साल पहले ठीक किया जाना चाहिए था, बिना एक दिन बर्बाद किए यह जांचना कि हमें यह समस्या क्यों हो रही थी।

मुझे विश्वास नहीं हो रहा है कि मैन्युअल रूप से यार्न.लॉक को संपादित करना, पैकेज को फिर से जोड़ना या चयनात्मक रिज़ॉल्यूशन का उपयोग करना एक अप्रत्यक्ष निर्भरता को अपडेट करने के "तरीके" हैं।

IMO, yarn upgrade को अप्रत्यक्ष निर्भरता को नवीनतम स्वीकृत सेवर संस्करण में अपडेट करना चाहिए, इसलिए हम एक पैकेज को अपग्रेड करते हैं। मेरा मतलब है, अगर सेवर रेंज में कोई ब्रेक होता है तो यह अप्रत्यक्ष निर्भरताओं को अपडेट करेगा, इसलिए इसे हमेशा करना चाहिए।

क्या ऐसा करने के लिए किसी प्रकार की बाहरी स्क्रिप्ट लिखने में मदद मिलेगी? मुझे लगता है कि यह दिए गए पैकेज के लिए सभी yarn.lock प्रविष्टियों को हटा देगा, और फिर यार्न को फिर से चलाएगा?

ऐसा करने के लिए एक सरल स्क्रिप्ट है: https://gist.github.com/pftg/fa8fe4ca2bb4638fbd19324376487f42

क्या कोई अनुरक्षक कृपया लेबल को cat-feature से cat-bug में बदल सकता है?

क्या कोई अनुरक्षक कृपया लेबल को कैट-फीचर से कैट-बग में बदल सकता है?

क्यों? यह एक बग नहीं है। यह जैसा डिजाइन किया गया है। yarn upgrade का इरादा कभी भी एक सकर्मक निर्भरता को अपग्रेड करने के लिए उपयोग करने का नहीं था। मूल रूप से खोला गया "मुद्दा" एक सुविधा अनुरोध के रूप में भी लेबल किया गया है।

आंतरिक रूप से upgrade $ यह निर्धारित करने के लिए yarn outdated $ का उपयोग करता है कि क्या पुराना है और किन संस्करणों में अपग्रेड करना है। outdated केवल प्रत्यक्ष निर्भरता की जाँच करता है।

मैं गलत हो सकता था, या शायद यह बदल गया है, लेकिन मुझे पूरा यकीन है कि npm upgrade कम से कम 3 साल पहले जब yarn upgrade को अंतिम बार फिर से तैयार किया गया था, यह भी एक तरीका प्रदान नहीं करता है एक ट्रांजिटिव डिपो अपग्रेड करें। (फिर से, यह वर्षों से बदल सकता है, मैं npm के परिवर्तनों पर बहुत अद्यतित नहीं हूं)।

इस कार्यक्षमता को जोड़ने के लिए कोई भी पीआर जमा करने के लिए स्वतंत्र है। यह एक ओपन सोर्स प्रोजेक्ट है और यह बड़े पैमाने पर समुदाय पर निर्भर करता है कि वह योगदान करे। यह सुविधा अनुरोध वर्षों से खुला है लेकिन किसी ने भी इसे लागू करने के लिए कदम नहीं उठाया है और इसीलिए इसे "तय" नहीं किया गया है।

@nnmrts क्या आप मेरी स्क्रिप्ट https://github.com/yarnpkg/yarn/issues/4986#issuecomment -562719589 देख सकते हैं, क्या यह अभी आपकी मदद करेगी?

@rally25rs क्षमा करें, मैं थका हुआ और क्रोधी था, मेरी टिप्पणी को सुलझा हुआ मानें। मैं

@nnmrts क्या आप मेरी स्क्रिप्ट #4986 देख सकते हैं (टिप्पणी) क्या यह अभी आपकी मदद करेगी?

दुर्भाग्य से वह स्क्रिप्ट मेरे काम नहीं आई, कल इसे आजमाया। हो सकता है कि मैंने कुछ गलत किया हो, लेकिन मेरी पूरी यार्न.लॉक फ़ाइल स्क्रिप्ट द्वारा "खाली" हो गई।

मुझे यकीन नहीं है कि यह कितना अच्छा समाधान है, लेकिन मैंने इस स्क्रिप्ट को चलाया जो मैंने लिखा था:

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)

फिर yarn install चला और ऐसा लगता है कि अप्रत्यक्ष निर्भरताओं के नवीनतम संस्करण स्थापित हैं।

मैं गहरी/अप्रत्यक्ष निर्भरताओं को सफलतापूर्वक हल करने में सक्षम था। मुझे आश्चर्य है कि हमें आधिकारिक समर्थन कब मिलेगा।

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

मैंने यार्न.लॉक को फिर से बनाने के जोखिमों को हल करने और समझाने की कोशिश की है और सुझाव दिया है कि क्या किया जाना चाहिए।

मुझे बताएं कि क्या यह आप लोगों के लिए भी काम करता है। या उन्नयन की प्रक्रिया में सुधार के लिए कोई सुझाव।

@ आयुष एचएम, यह काम करने लगता है, प्रतिभाशाली।

मुझे आश्चर्य है कि क्या यार्न एक पैच को स्वीकार करेगा जिसमें yarn upgrade एक अप्रत्यक्ष निर्भरता (या कुछ अन्य कमांड?)

@jrochkind मैं एक अप्रत्यक्ष निर्भरता के yarn upgrade को अपग्रेड करने की अपेक्षा करता, भले ही यह मेरी प्रत्यक्ष निर्भरता न हो। उस सुविधा के बिना, आप अप्रत्यक्ष निर्भरता के अपडेट पर वर्षों पीछे रह सकते हैं।

मेरे मामले में, मैं fsevents को अपग्रेड करने की कोशिश कर रहा था, ताकि जब मैंने yarn install (https://github.com/fsevents/fsevents/issues/278) किया तो इसमें त्रुटियां नहीं थीं। ) fsevents एक पैकेज नहीं है जिसका मैं सीधे उपयोग करता हूं - यह कुछ ऐसा है जो webpack-dev-server उपयोग करता है। लेकिन हैरानी की बात यह है कि जब इस ऐप में पहली बार webpack-dev-server इंस्टॉल किया गया था, तो मुझे उस संस्करण के लिए लॉक कर दिया गया था।

मुझे इसे अपग्रेड करने के लिए इस ट्रिक का इस्तेमाल करना पड़ा, जो कुल हैक की तरह लग रहा था। https://github.com/yarnpkg/yarn/issues/4986#issuecomment -395036563

वर्कअराउंड मेरे लिए काम नहीं कर रहा है, दुर्भाग्य से, पुरानी गहरी-निर्भरता को फिर से यार्न.लॉक फ़ाइल में हटाने के बाद जोड़ा गया था। मैं उन्हें वापस node_modules फ़ोल्डर और यार्न.लॉक फ़ाइल में यार्न इंस्टॉल चलाने के बाद देख सकता हूं।

शायद वर्कअराउंड यार्न वर्कस्पेस के साथ संगत नहीं है?

@FelipeLujan जब वर्कअराउंड काम करता है, तब भी गहरी-निर्भरता को फिर से यार्न.लॉक फ़ाइल में जोड़ा जाता है - जो अपेक्षित है - लेकिन नए बाद के संस्करणों के साथ। लेकिन केवल नए संस्करणों के साथ यदि नए संस्करण जारी किए गए हैं , और यदि उन्हें निर्भरता पेड़ द्वारा अनुमति दी गई है। अगर कुछ मध्यस्थ निर्भरता एक प्रतिबंध व्यक्त करती है जो उन्नयन की अनुमति नहीं देती है, तो भी उन्हें अपग्रेड नहीं किया जा सकता है। उन्हें पेड़ में प्रतिबंधों द्वारा अनुमत नवीनतम में अपग्रेड किया गया है।

हालांकि मैं यार्न वर्कस्पेस का उपयोग नहीं करता, इसलिए यह नहीं कह सकता कि यह प्रासंगिक है या नहीं।

@FelipeLujan AFAIK यार्न वर्कस्पेस एक समान तरीके से काम करते हैं।

पैकेज अनुभाग को हटाने का समाधान केवल पैकेज को नवीनतम MINOR/PATCH संस्करण में अपग्रेड करेगा।
यदि आप पैकेज को एक नए प्रमुख संस्करण में अपग्रेड करना चाहते हैं तो आपको पैकेज निर्भरता श्रृंखला yarn why package-name-here चल रही है और पैकेज को इसकी श्रृंखला के शीर्ष पर अपग्रेड करना होगा।

चेतावनी: अपने कोड का परीक्षण करें क्योंकि संकुल को नए MAJOR संस्करण में अपग्रेड करने से कुछ महत्वपूर्ण परिवर्तन हो सकते हैं।

https://github.com/djmitche/yarn-minify इससे मदद मिल सकती है।

@ayushya का समाधान मेरे लिए बहुत अच्छा काम कर रहा है, एक अप्रत्यक्ष निर्भरता को हटाने के लिए मैन्युअल रूप से यार्न.लॉक को संपादित करना, फिर बाद के संस्करण में इसे फिर से जोड़ने के लिए यार्न इंस्टॉल चलाना।

मेरे लिए, यह एक ऐसी सुविधा की तरह लगता है जिसे यार्न में मैन्युअल रूप से संपादित करने की आवश्यकता के बजाय, यार्न में बनाया जाना चाहिए।लॉक। ऐसा लगता है कि यह एक सुविधा बनाने के लिए काफी सख्त होना चाहिए, जैसे कि आपने निर्भरता को हटाने और यार्न इंस्टॉल चलाने के लिए मैन्युअल रूप से संपादित किया था। मुझे लगता है कि इस सुविधा को वास्तव में यार्न में बनाया जाना चाहिए, और मैं थोड़ा उलझन में हूं कि ऐसा क्यों नहीं है।

मैं गहरी/अप्रत्यक्ष निर्भरताओं को सफलतापूर्वक हल करने में सक्षम था। मुझे आश्चर्य है कि हमें आधिकारिक समर्थन कब मिलेगा।

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

मैंने यार्न.लॉक को फिर से बनाने के जोखिमों को हल करने और समझाने की कोशिश की है और सुझाव दिया है कि क्या किया जाना चाहिए।

मुझे बताएं कि क्या यह आप लोगों के लिए भी काम करता है। या उन्नयन की प्रक्रिया में सुधार के लिए कोई सुझाव।

मुझे लगता है कि यह वही संकल्प @ alex-thewsey-ibm द्वारा दिया गया है। उस विशेष निर्भरता को यार्न.लॉक से हटाने से मुझे मदद मिली।
बहरहाल, इस हैक के लिए धन्यवाद☺️

resolutions का उपयोग $# package.json में मेरे लिए काम किया https://github.com/webpack/webpack-dev-server/issues/2739#issuecomment -695164486

इसे कम से कम कुछ चेतावनी वापस करनी चाहिए:

yarn add [email protected]
yarn upgrade is-alphabetical

इसके बजाय मुझे यही मिलता है:

success Saved lockfile.
success Saved 0 new dependencies.

package.json और yarn.lock में शून्य परिवर्तन हैं, भले ही एक नया is-alphabetical पैकेज संस्करण उपलब्ध हो।