Yarn: كيفية ترقية التبعيات غير المباشرة؟

تم إنشاؤها على ٢٣ نوفمبر ٢٠١٧  ·  45تعليقات  ·  مصدر: yarnpkg/yarn

هل تريد طلب ميزة أو الإبلاغ عن خطأ ؟

ميزة.

ما هو السلوك الحالي؟
يتجاهل yarn upgrade التبعيات غير المباشرة ، لذلك لا يمكن للمستخدمين ترقيتها في yarn.lock. إذا فاتني شيء ، من فضلك قل لي.

إذا كان السلوك الحالي عبارة عن خطأ ، فيرجى تقديم خطوات إعادة الإنتاج.

  • افترض مشروعًا جديدًا فارغًا ، قم بتشغيل yarn add [email protected]

    • 2 تبعيات غير مباشرة ، is-alphabetical و is-decimal ، سيتم تثبيتها وحفظها في yarn.lock

    • أحدث إصدار من is-alphabetical هو 1.0.1 الآن ، إذا تم إصدار إصدار جديد آخر ، على سبيل المثال 1.0.2 (للاختبار ، يمكنك إصدار حزمتين اختباريتين بنفسك أو تعديل is-alphabetical ليكون 1.0 .0 في yarn.lock ، * أعلم أن تعديل yarn.lock مباشرة ليس عملية عادية *)

  • بغض النظر عن أي من الطرق التالية ، فإن yarn يشير دائمًا All of your dependencies are up to date

    • ترقية الغزل هي الأبجدية

    • ترقية الغزل التفاعلية

    • ترقية الغزل التفاعلية هي أبجدية

ما هو السلوك المتوقع؟
يدعم yarn upgrade أيضًا التبعيات غير المباشرة.

يرجى ذكر node.js والغزل وإصدار نظام التشغيل.
العقدة 8.9.0
غزل 1.3.2
OSX 10.12.6

cat-feature

التعليق الأكثر فائدة

+1 لطلب هذه الميزة. أيضًا مثال لأي شخص غبي مثلي يحتاج إلى ترقية تبعية غير مباشرة محددة يدويًا في غضون ذلك:

بالنظر إلى التبعية الصريحة ، فإن jsonwebtoken قد حل التبعية الضمنية jws^3.0.0 للاختراق jws=3.1.4 : وتحتاج بدلاً من ذلك إلى حل مشكلة 3.1.5 :

احذف الإدخال jws سبيل المثال أدناه من yarn.lock ، وأعد تشغيل 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"

تحرير: علامات الترقيم

ال 45 كومينتر

chinesedfan هل جربت yarn upgrade-interactive ؟

milesj نعم ، ينتج عنه نفس النتيجة ولقد قمت أيضًا بتحديث خطوات إعادة الإنتاج في وصف المشكلة.

هذا لأن yarn add [email protected] يضبط package.json على الإصدار _exactly_ 1.0.0 كما طلبت.

يحترم yarn upgrade نطاق semver الخاص بـ package.json ، وبما أنك حددت الإصدار 1.0.0 بالضبط ، فلن يعرض الترقية إلى إصدارات أخرى.

يمكنك حل هذا بطريقتين:

  • yarn upgrade --latest سيتجاهل نطاق semver ويرى ما تم وضع علامة عليه كـ latest في التسجيل.
  • قم بتغيير package.json لقبول نطاق إصدار مثل ^1.0.0 ثم yarn upgrade (قد تضطر إلى 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 شكرا لردكم! اختبرت حالتين أخريين.

  • yarn upgrade is-alphabetical --force لا يعمل أيضًا.
  • سيقوم yarn upgrade is-alphanumerical بترقية كل تبعياته الفرعية حتى لو كانت الأحدث بالفعل.

    • ولكن إذا كنت أرغب فقط في ترقية اعتماد فرعي محدد ، فهذا لا يزال غير ملائم للغاية.

نعم ، هذه مشكلة كبيرة في الغزل في الوقت الحالي. وهو بالفعل قيد المناقشة في # 2394

مكررة # 2394

من فضلك ، أعد الفتح: إنها ليست مكررة.

يصف 2394 تكرار الحزمة meck-test-bb (تبعية غير مباشرة):

حصلت على نسختين من meck-test-bb

تصف هذه المشكلة فقط القدرة على ترقية التبعية غير المباشرة (بطريقة ما).

@ rally25rs سامحني على ping.

@ rally25rs ، من فضلك ، لقد أغلقت كلتا المشكلتين غير المكررة ، هذا خطأ. أعطنا القدرة على ترقية التبعيات غير المباشرة ، من فضلك!

عذرا ، كان هناك بعض الالتباس حول القضية الأخرى. اعتقدت في الأصل أن 2394 كان يطلب طريقة لترقية وحدة إدارة متعدية باستخدام علامة --deep ، أو شيء من هذا القبيل ، لذلك قمت بتمييز هذه المشكلة على أنها نسخة مكررة من ذلك. في وقت لاحق بعد إعادة قراءة 2394 ، أعتقد أنه كان حول شيء مختلف ، وهو ليس نسخة طبق الأصل من هذا كما كنت أعتقد في الأصل.

+1 لطلب هذه الميزة. أيضًا مثال لأي شخص غبي مثلي يحتاج إلى ترقية تبعية غير مباشرة محددة يدويًا في غضون ذلك:

بالنظر إلى التبعية الصريحة ، فإن jsonwebtoken قد حل التبعية الضمنية jws^3.0.0 للاختراق jws=3.1.4 : وتحتاج بدلاً من ذلك إلى حل مشكلة 3.1.5 :

احذف الإدخال jws سبيل المثال أدناه من yarn.lock ، وأعد تشغيل 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"

تحرير: علامات الترقيم

@ alex-thewsey-IBM ، شكرًا على الحل!

عملت على الغزل v1.7.

تي واي ، عملت الغزل 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"
  }
}

نحتاج إلى هذه الميزة في Autoprefixer لنقترح على المستخدمين كيفية تحديث caniuse-lite في yarn.lock https://github.com/postcss/autoprefixer/issues/1184

نفس المشكلة هنا. كنت أتوقع أن يقوم yarn upgrade caniuse-lite browserslist بترقية التبعية الفرعية. لم يفعل ذلك ، ولم يعطيني رسالة خطأ تفيد بأنه لا يمكنه ترقيته ب / ج ، فهو ليس تبعية.

اقترح حذف إدخالات ملف القفل ذات الصلة ثم إعادة تشغيل yarn كـ @ alex-thewsey-ibm حل المشكلة الفورية بالنسبة لي.

من الغريب بالنسبة لي أن الغزل يفتقد ميزة tnis. أنا جديد في مجال الغزل (و npm) ، لذلك افترض أنه يجب أن تكون هناك طريقة للقيام بذلك. ما زلت غير متأكد تمامًا مما إذا كانت هناك طريقة غير واضحة للقيام بذلك لا يعرفها أحد في هذا الموضوع ، أو إذا لم يكن هناك حقًا طريقة للقيام بذلك.

إذا لم تكن هناك طريقة فعلاً لترقية تبعية متعدية / غير مباشرة في ملف القفل دون إضافتها إلى package.json ... لا أفهم كيف يفعل مستخدمو الغزل بدونها.

هذا سلوك غير متوقع IMO - لقد حاولت تحديث الملف مؤخرًا بـ yarn upgrade [email protected] وما زال لم يتم تحديثه لأي تبعية عابرة.

بقيت مع كل إصدارات major (^ 4.XX) و patch (4.17.X تقريبًا) التي تشير إلى الإصدار القديم.

الطريقة الوحيدة لإصلاحها هي عن طريق التحرير اليدوي لـ yarn.lock ثم ربما تشغيل yarn upgrade لدمج التغييرات. أتوقع أفضل قليلاً من هذه الأداة المستخدمة على نطاق واسع.

هل هذا الخطأ المعترف به أو الغزل متحفظ بشكل افتراضي ومن المتوقع أن أقوم بتحرير yarn.lock يدويًا أو استخدام بعض العلامات؟

أظن أن لدي نفس التنبيه الأمني ​​الذي يجب حله مثل Machiaweliczny ؛) سيكون من المفيد حقًا تجاوز التبعية غير المباشرة أثناء انتظار المشاريع لإصلاح مشاريعها الخاصة. حتى مع المشروعات عالية الاستجابة ، هناك تأخير في انتظار الإصلاحات والإصدارات.

في الواقع ، هذا يمثل مشكلة بالنسبة لقضايا الأمان في التبعيات غير المباشرة ، والحل البديل لتحرير yarn.lock ، رغم فعاليته ، مخيب للآمال ويصعب أتمتة. إذا لم يكن هذا هو السلوك الافتراضي لسبب ما ، فسيكون من الرائع إضافة خيار مثل --include-indirect والذي سيجبر Yarn على اتباع التبعيات غير المباشرة.

لا أعتقد أنه يجب أن يحتاج إلى خيار ، لا أرى لماذا لا يقوم yarn upgrade [an indirect dependency] فقط بتحديث yarn.lock إلى أحدث إصدار من التبعية غير المباشرة التي تسمح بها شجرة التبعية ، دون الحاجة إلى خيارات اضافية. أعتقد أنه الآن مجرد عدم عمل؟

ومع ذلك ، هناك حل آخر وجدته سعيدًا وهو إضافة resolutions إلى package.json الخاص بي. إذا كان lodash تبعية غير مباشرة ، وأنا أعلم أنني بحاجة إلى أن يكون> ​​= 4.7.13 لتجنب ثغرة أمنية ، يمكنني أن أضيف إلى الحزمة الخاصة بي. json:

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

ثم قم بتشغيل yarn install ، وسوف يقوم بتحديث yarn.lock لتلبية هذا المطلب ، أو يشتكي إذا لم يستطع لأنه يتعارض مع التبعية غير المباشرة.

يبدو أن هذا في الواقع قد نجح بشكل جيد في حالتي ؛ أتساءل ما إذا كان هذا ليس "حلًا" ولكن الحل المقصود؟ استغرق الأمر مني بعض الوقت لاكتشاف بالرغم من ذلك. وأنا لا أفهم الأشياء جيدًا بما يكفي لأتأكد من أن هذا حل شامل / صحيح أو إذا كان هناك أي مشاكل في بعض الحالات معه. إذا كان هذا هو الحل "الصحيح" لترقية التبعيات غير المباشرة ، فقد كان من الصعب إلى حد ما العثور عليه.

لماذا لا تقوم الغزل بتثبيت القسم الانتقالي الذي تريد تحديثه ولكن لا تلتزم بتغييرات package.json ، فقط yarn.lock؟

لماذا لا تقوم الغزل بتثبيت القسم الانتقالي الذي تريد تحديثه ولكن لا تلتزم بتغييرات package.json ، فقط yarn.lock؟

لا أعتقد أن هذا سيعمل (دائمًا؟) ، لأن الغزل سيثبت لحسن الحظ إصدارات متعددة من نفس الحزمة ، حتى لو كان إصدار واحد يلبي جميع نطاقات semver ذات الصلة. لذلك سيؤدي هذا إلى تثبيت الإصدار الذي تريده ، ولكن لن يزيل الإصدار الذي لا تريده.

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 من التبعية.
تبين أنه كان هناك خطأ سيئ جدًا كان يفشل بصمت في منتجنا والذي كان يجب إصلاحه قبل عام دون أن أضيع يومًا في التحقيق في سبب وجود هذه المشكلة.

لا أصدق أن تحرير yarn.lock يدويًا ، وإزالة الحزمة ثم إعادة إضافتها أو استخدام الدقة الانتقائية هي "الطرق" لتحديث تبعية غير مباشرة.

يجب أن تقوم IMO ، yarn upgrade بتحديث التبعيات غير المباشرة إلى أحدث إصدار semver المقبول ، ولهذا السبب نقوم بترقية الحزمة. أعني ، إذا كان هناك انقطاع في نطاق semver ، فسيحدث التبعيات غير المباشرة ، لذلك يجب أن يفعل ذلك دائمًا.

هل سيساعد كتابة نوع من البرامج الخارجية للقيام بذلك؟ أفترض أنه سيؤدي فقط إلى إزالة جميع الإدخالات yarn.lock للحزمة المحددة ، ثم إعادة تشغيل الغزل؟

يوجد نص بسيط للقيام بذلك: https://gist.github.com/pftg/fa8fe4ca2bb4638fbd19324376487f42

هل يمكن لأحد المشرفين تغيير التسمية من cat-feature إلى cat-bug ؟

هل يمكن لأحد المشرفين تغيير الملصق من ميزة cat إلى 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 (تعليق) هل سيساعدك في الوقت الحالي؟

هذا البرنامج النصي للأسف لم يعمل معي ، جربته بالأمس. ربما فعلت شيئًا خاطئًا ، لكن ملف yarn.lock بأكمله تم "إفراغه" بواسطة البرنامج النصي.

لست متأكدًا من مدى جودة هذا الحل ، لكنني قمت بتشغيل هذا البرنامج النصي الذي كتبته:

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-pack-Depencies-using-yarn-8b5983d5fb6b

لقد حاولت حل وشرح مخاطر إعادة إنشاء خيوط الغزل واقترحت ما يجب القيام به.

اسمحوا لي أن أعرف إذا كان هذا يعمل معكم أيضا يا رفاق. أو أي اقتراحات لتحسين عملية الترقية.

ayushya Hm ، يبدو أن هذا يعمل ، عبقري.

أتساءل عما إذا كان الغزل سيقبل رقعة يكون فيها 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

الحل لا يعمل بالنسبة لي ، لسوء الحظ ، تمت إضافة التبعيات القديمة مرة أخرى إلى ملف yarn.lock بعد حذفها. يمكنني رؤيتهم مرة أخرى في مجلد node_modules وملف yarn.lock بعد تشغيل تثبيت الغزل.

ربما الحل غير متوافق مع مساحات عمل الغزل؟

FelipeLujan عندما يعمل الحل البديل ، لا تزال تضاف التبعيات العميقة مرة أخرى إلى ملف yarn.lock - وهذا متوقع - ولكن مع الإصدارات الأحدث الجديدة. ولكن فقط مع الإصدارات الجديدة إذا كانت هناك إصدارات جديدة تم إطلاقها ، وإذا كانت شجرة التبعية تسمح بها. إذا عبرت بعض التبعية للوسيط عن قيود لا تسمح بالترقية ، فلا يزال يتعذر ترقيتها. لقد تمت ترقيتهم إلى أحدث ما تسمح به القيود في الشجرة.

لا أستخدم مساحات عمل الغزل ، لذا لا يمكنني تحديد ما إذا كان ذلك مناسبًا.

مساحات عمل خيوط FelipeLujan AFAIK تعمل بطريقة مماثلة.

سيؤدي الحل البديل لحذف قسم الحزمة فقط إلى ترقية الحزمة إلى أحدث إصدار من MINOR / PATCH .
إذا كنت ترغب في ترقية الحزمة إلى إصدار رئيسي أحدث ، يجب عليك العثور على سلسلة تبعية الحزمة التي تعمل yarn why package-name-here وترقية الحزمة في الجزء العلوي من سلسلتها.

تنبيه: اختبر الكود الخاص بك لأن ترقية الحزم إلى إصدار رئيسي أحدث قد يؤدي إلى بعض التغييرات العاجلة.

https://github.com/djmitche/yarn-minify قد يساعد في هذا ..

يعمل حل ayushya بشكل رائع بالنسبة لي ، حيث يقوم يدويًا بتحرير yarn.lock لإزالة التبعية غير المباشرة ، ثم تشغيل تثبيت الغزل لإعادة إضافته في إصدار لاحق.

بالنسبة لي ، يبدو هذا وكأنه ميزة يجب تضمينها في الغزل ، بدلاً من مطالبتك بتحرير yarn.lock يدويًا. يبدو أنه يجب أن يكون من السهل جدًا إنشاء ميزة تبدو كما لو كنت قد قمت بتحريرها يدويًا لحذف التبعية وتشغيل تثبيت الغزل. أشعر أن هذه الميزة يجب أن تكون مدمجة حقًا في الغزل ، وأنا في حيرة من أمري حول سبب عدم وجودها.

تمكنت من حل التبعيات العميقة / غير المباشرة بنجاح. أتساءل متى سنحصل على دعم رسمي.

https://medium.com/@ayushya/upgrading -javascript-pack-Depencies-using-yarn-8b5983d5fb6b

لقد حاولت حل وشرح مخاطر إعادة إنشاء خيوط الغزل واقترحت ما يجب القيام به.

اسمحوا لي أن أعرف إذا كان هذا يعمل معكم أيضا يا رفاق. أو أي اقتراحات لتحسين عملية الترقية.

أعتقد أن هذا هو نفس القرار الذي قدمه @ alex-thewsey-IBM. ساعدني حذف تلك التبعية الخاصة من yarn.lock.
على أي حال ، شكرًا على هذا الاختراق

استخدام 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 جديد.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات