<p>ربما يجب ألا يخزن الغزل الحزم التي تم حلها باستخدام مسار الملف</p>

هذا خدعني ايضا يجب أن تكون هناك طريقة للتغلب على هذا دون مسح ذاكرة التخزين المؤقت بالكامل.

أعتقد أن هناك ثلاث طرق لجعل الغزل صالحًا للاستخدام في هذه الحالة:

1. اقتراحdonaldpipowitch بتجاهل جميع التبعيات المحلية.
2. إعادة تثبيت التبعيات المحلية إذا تم تعديل الملف الموجود في وقت لاحق عن وقت تخزينه مؤقتًا. سيتطلب ذلك منا الاحتفاظ بهذه البيانات الوصفية. بالنسبة إلى التبعيات المحلية ، قد نقوم بإدراج أسطر مثل هذه في عمود "تم الحل": file://<path>@<cache_timestamp>
3. تجاهل الحزم حسب أسماء الحزم بأوامر مثل yarn cache rm <package> و yarn cache add <package> . لجميع التبعيات.

أود أن أرى الاقتراح الثاني ليتم تنفيذه. ما لم يكن الخيار الثالث مفيدًا في حالات أخرى أيضًا. على سبيل المثال ، يمكن استخدام yarn cache add <package> لتحديث ذاكرة التخزين المؤقت للاعتماديات المخزنة مؤقتًا بالفعل في حالة حدوث خطأ ما أثناء تنزيل التبعية.

hantuzun لماذا تخزين التبعيات المحلية مؤقتًا على الإطلاق؟ إنها محلية على أي حال ، لذلك ستكون سريعة بغض النظر عن ذاكرة التخزين المؤقت أم لا.

@ satya164 أنت على حق. على الرغم من أنني أميل أكثر إلى النهج الثالث من شأنه أن يساعد إذا تم تعديل التبعية من الشبكة عن قصد.

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

هل يستطيع أحد أن يشرح لي المنطق الداخلي؟

فهمي:
عند مواجهة تبعية بـ file: تبدأ عملية التبعية file-resolver.js . وتقول إن التبعية يجب نسخها وعدم تجزئتها . ألا يعني عدم وجود تجزئة أنه لا يجب تخزينها مؤقتًا بالفعل ...؟ ولكن يبدو أن copy-fetcher.js بتعيين التجزئة على سلسلة فارغة بدلاً من الاحتفاظ بـ null ... هل هذه مشكلة؟

@ bestander أو @ kittens ربما يمكنك شرح هذا أكثر قليلاً ...؟ أحب الحصول على القليل من المساعدة لإنشاء العلاقات العامة ♥

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

ربما يمكنك أن تبدأ بعلاقات عامة تضيف اختبارات وحدة مكسورة

حسنًا ، شكرًا لك على ردك. هل يجب أن أرسل اتصالاً إليك بصفتك مراجعًا في العلاقات العامة أم يجب أن أتواصل مع شخص آخر (أو لا أحد) ...؟

نعم ، أرسل لي

bestander ربما لا يجب إغلاق هذه المشكلة لأنها لم يتم حلها بعد؟

نعم ، يجب إعادة فتحه. تم إغلاقه لأنني كتبت "إصلاحات # 2165" في عنوان العلاقات العامة الخاصة بي. في البداية اعتقدت أنه سيكون عبارة عن علاقات عامة مستمرة ، ولكن لإصلاح هذا الخطأ ، نريد اثنين من العلاقات العامة: الأول أضاف اختبار وحدة (التأكيد الذي سيفشل ليس نشطًا حقًا ، لذلك لا تنفجر CI) و والثاني سيصلحه بالفعل.

آسف ، جيثب يغلق المشاكل عند دمج العلاقات العامة

لذلك من الواضح أن هذا لا يزال يمثل مشكلة؟ لأكون صادقًا ، من المزعج جدًا تطويره. لقد تسبب لي قليلاً من الاضطراب على المستوى الشخصي في العمل ، حيث أستفيد من file: لإنشاء بيئة تطوير معيارية. الجزء الممتع هو أن كل حزمة محلية أقوم بتحريرها (باستخدام المسار file: في package.json ) ، تتطلب القيام بذلك ، من أجل سحب المحتويات التي تم تحديثها:

تحرير محتويات حزمة eslint-config-base-eslint الخاصة بي

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

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

أعتقد بالفعل أن الإصلاح يجب أن يكون من 10 إلى 15 سطرًا من التعليمات البرمجية ، فمن المحتمل أن يوفر الكثير من الوقت لإصلاحه عاجلاً

لمعلوماتك: قد تكون هذه المشكلة ذات صلة أيضًا بالخطوات البطيئة linking dependencies . انظر تعليقي هنا: https://github.com/yarnpkg/yarn/issues/1496#issuecomment -282688818.

آسف. لم أجد الوقت لإنشاء علاقات عامة أخرى لهذه المشكلة :( كنت (وما زلت) مشغولًا للغاية.

bestander هذا مانع كبير جدًا بالنسبة لي ، حيث أعمل في مشروع متعدد الوحدات. إذا كنت أقرأ ارتباطات وتعليقات التعليمات البرمجية الخاصة بـ donaldpipowitch بشكل صحيح ، hash جديدًا (بدلاً من null) في كل مرة يحاول فيها حل المشكلة حتى يفرض إعادة التثبيت؟ قل UUID أو الطابع الزمني الحالي؟ سامحني إذا فاتني شيء ، فأنا لست على دراية بالطريقة التي يعمل بها الكود.

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

في الثلاثاء ، 7 مارس 2017 الساعة 03:38 ، كتب Matt Traynham [email protected] :

bestander https://github.com/bestander هذا مانع كبير جدًا
بالنسبة لي ، أعمل في مشروع متعدد الوحدات. إذا كنت أقرأdonaldpipowitch
https://github.com/donaldpipowitch روابط وتعليقات كود الكود
بشكل صحيح ، هل يمكننا أن نجعل محلل الملفات ينشئ تجزئة جديدة (بدلاً من
null) في كل مرة يحاول فيها حل المشكلة ، فذلك يفرض إعادة التثبيت؟ قل UUID
أو الطابع الزمني الحالي؟ سامحني إذا فقدت شيئًا ، فأنا لست مألوفًا
مع طريقة عمل الكود.

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/yarnpkg/yarn/issues/2165#issuecomment-284612526 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ACBdWDS3xSr8KNu1o9Zn8sA9xdO8pyHOks5rjNEmgaJpZM4LFbmf
.

@ bestander فيما يتعلق ربطه بالرمز بدلاً من نسخ الملفات؟ أم أن هناك أي سبب لعدم القيام بذلك؟

يبدو أن windowsdanrot يتطلب من المسؤول الارتباط الرمزي.
كما أنه يعبث بالتكرار للعثور على وحدات العقدة

يتجاهل Symlink أيضًا .npmignore وأشياء من هذا القبيل. (والذي يبدو أنه تم تجاهله أيضًا حاليًا. والذي قد يكون مشكلة: https://github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818)

هل هناك أي حل بديل لهذا المنع حاليًا لمسح ذاكرة التخزين المؤقت بالكامل؟ لسوء الحظ ، يبدو أنه لا يوجد أمر من نوع yarn cache rm package .

@ rhys-e أستخدم هذا البرنامج النصي الصغير:

#!/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

هل حاول أي شخص فقط yarn link كل التبعيات المحلية على postinstall ؟ يبدو وكأنه الحل المناسب حتى تصل إلى الأراضي المناسبة.

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

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

سينشئ رابط رمزي تحت الغطاء ، مما يعني أنه سيتم استخدام أحدث إصدار محلي. لكنني أعتقد أن وجود برنامج نصي ، قبل أن ينظف التثبيت ذاكرة التخزين المؤقت لقسم معين هو الحل الصحيح الآن.

لقد اختبرت مجموعات مختلفة في العمل حول التغييرات في الحزمة المحلية التي لم يتم تحديثها في الإصدار المثبت للمشروع الأصلي ضمن ./node_modules/. أجد أن هذا فقط سيفي بالغرض ، دون الحاجة إلى حذف ./node_modules/أول:

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

وغني عن القول ، يجب ألا يكون فرض تنظيف ذاكرة التخزين المؤقت العامة يدويًا ضروريًا لتحديث / ترقية الحزم المحلية.

fungilation كحل بديل ، يمكنك أيضًا استخدام npm لتثبيت التبعيات المحلية وبالتالي تجنب فقد ذاكرة التخزين المؤقت بالكامل في كل مرة تريد فيها التحديث.

لكل # 2860 والدمج اللاحق الالتزام https://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24 ، يمكنك الآن "تحديث" file: تبعيات البروتوكول باستخدام

yarn install --force

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

yarn upgrade [file protocol package name]

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

لقد تم توضيح لي أيضًا أن هناك RFC نشطًا لربط التبعيات ، ربما باستخدام بروتوكول link: . يمكن اتباع ذلك هنا ، https://github.com/yarnpkg/rfcs/pull/34.

mtraynham شكرا لك على طلب السحب الخاص بك! 👌 هذا رائع. أي أسباب لماذا --force مطلوب؟ لا أعرف حاليًا ما الذي تفعله بالضبط الآن دون البحث عنه :) فقط أسأل ، لأن npm لا تحتاج إلى --force flag وكان من الجيد أن تتصرف مثل npm.

تحرير يبدو أن yarn upgrade [dependency] يعمل أيضًا. أريد أن أشير إلى أن هذا لا يغير دائمًا ملف القفل ، والذي يجب أن يعكس فقط تغييرات إصدار package.json. لقد قمت بتحديث منشوري الأصلي ، لأن الترقية ربما تكون أكثر ملاءمة.

الإصدار المختصر هو أن Yarn لن تفعل أي شيء مع محللات ذاكرة التخزين المؤقت إذا لم يتغير ملف القفل ، لذلك نحتاج إلى تخطي فحص ملف القفل ونسأل ذاكرة التخزين المؤقت إذا كان هناك إصدار أحدث. يمكن القيام بذلك باستخدام upgrade أو install --force

لكل وثائق yarn install --force

"يعيد تغليف جميع الحزم ، حتى تلك التي تم تثبيتها مسبقًا".

هذا يعني حقًا أنه سيتخطى فحص سلامة ملف القفل. عادةً ما ينجح فحص سلامة ملف القفل إذا لم تقم بتغيير ملف package.json وإنقاذك بأمان. يؤدي تخطيها إلى مطالبة ذاكرة التخزين المؤقت بالتحقق من التبعيات المفقودة / غير المتطابقة مقابل ملف القفل ، وتنزيلها إذا كانت مفقودة ، ونسخ أي تبعيات جديدة / مفقودة مرة أخرى محليًا. ثم يتم تشغيل البرامج النصية npm install / postInstall .

سيؤدي تغيير PR الآن إلى إبطال التبعية file: في ذاكرة التخزين المؤقت ونسخ الإصدار الجديد لأسفل محليًا. قبل ذلك ، لن يبطل التبعية file: أبدًا. بالنسبة للبروتوكولات الأخرى ، إذا لم تقم بتغيير ملف package.json الخاص بك ، فلن يتغير (في ذاكرة التخزين المؤقت ومحليًا).

فماذا يعني ذلك بالنسبة لنا؟ لدي حوالي 60 تبعيات في مشروع (تتراوح من Angular إلى Webpack) ، مع تبعية واحدة file: . في الثانية install --force ، حيث أريد فقط تحديث التبعية المحلية ، يستغرق الأمر حوالي 5 ثوانٍ تقريبًا (من 1.5 ثانية تقريبًا مقابل yarn install ). بالنسبة لي ، هذا لا يكاد يذكر ، وأنا في الواقع معجب جدًا بمدى ضآلة عمل الغزل الذي يحاول أداءه خلال العملية برمتها.

إذا كان هناك أمر CLI آخر لتخطي فحص ملف القفل والتحقق من ذاكرة التخزين المؤقت لتبعية الملف المعين فقط ، فمن المحتمل أن يكون ذلك أسرع ، لكنني لم أجد واحدًا.

بعد كل ما قيل ، ما زلت أسمي هذا إسعافات أولية. يمكن استبدال هذا بحل أفضل مثل link: ؛ لا أعتقد أن أي شخص يهتم حقًا بتخزين التبعيات المحلية مؤقتًا. على الأقل ، فإن النفقات العامة المضافة لاستخدام install --force أو upgrade غالبًا ما تكون إهمالًا ولم يعد عليك yarn cache clean; mv node_modules /tmp/ .

جواب رائع. 👏 شكرا لك على تدوين هذا.

هل يقوم الغزل بالكتابة فوق ملفات المشروع المحلية المرتبطة بملفات من ذاكرة التخزين المؤقت للغزل؟ (لأنه يبدو أن هذا ما يحدث)

سيؤدي تغيير PR الآن إلى إبطال الملف: التبعية في ذاكرة التخزين المؤقت ونسخ الإصدار الجديد لأسفل محليًا.

هل هذا يعني أنه كلما اتصلت بـ $ yarn داخل حزمة بها "foo": "file:../" كتبعية ، سيتم إنشاء نسخة جديدة من "file:../" ؟

على سبيل المثال ، لدي حزمة بها أمثلة متعددة وهي أيضًا حزم:

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

ويبدو أن لدي foo 10 مرات الآن في ذاكرة التخزين المؤقت للغزل. أختبر أيضًا الأمثلة الخاصة بي على كل تغيير إصدار foo (ولدي عدة وحدات تم تكوينها بهذه الطريقة ، وليس فقط foo ) لذلك يبدو أن ذاكرة التخزين المؤقت للغزل الخاصة بي تنمو _حقيقة_ بسرعة حاليًا.

هل هذا هو السلوك الصحيح؟

أعتقد أنه بديل أفضل من وجود نسخة قديمة في ذاكرة التخزين المؤقت.
باستخدام الغزل 0.26 ، يمكنك استخدام link: لإنشاء روابط رمزية بدلاً من نسخ الملفات.
كما نعمل على مساحات عمل من شأنها أتمتة إنشاء رابط الرمز ، https://github.com/yarnpkg/yarn/issues/3294

نعم ، أتطلع إلى أماكن العمل

link: لا يعمل مع npm ، أليس كذلك؟ (لأن https://github.com/npm/npm/pull/15900 لا يزال مفتوحًا.)

من التصحيح npm 5 ، يتم الآن file: :

npm install ./packages/subdir سينشئ الآن رابطًا رمزيًا بدلاً من التثبيت العادي. file: لن يتم تغيير

حسنًا ، لا يوجد link مع npm.

npm install ./packages/subdir سينشئ الآن رابطًا رمزيًا بدلاً من التثبيت العادي

كندة مؤسفة. لم تتصرف إدارة الملفات أبدًا بنفس الطريقة نظرًا لنسخ كل شيء (بما في ذلك node_modules ) وعدم احترام الحقل .npmignore أو files . الآن أصبح الأمر أسوأ مع الارتباط الرمزي.

أعتقد أن الملف: والرابط: يمكن تحسينه بشكل أكبر ، فهناك استراتيجيات مختلفة لها PROs و CONs الخاصة بها ويجب أن تسمح الغزل للأشخاص باختيار واحدة.
على سبيل المثال ، يمكن تنفيذ knit RFC كإحدى الاستراتيجيات https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md

تضمين التغريدة

أعتقد أنه بديل أفضل من وجود نسخة قديمة في ذاكرة التخزين المؤقت.

أو هكذا ستصدق حتى نفاد مساحة القرص وتجد أن ذاكرة التخزين المؤقت لـ Yarn تستخدم عشرات الجيجابايت لملايين الملفات عديمة الفائدة تمامًا .
IMO الذي يجعل الأمر برمته أكثر خطورة مما كان عليه من قبل ، لأنك تكتشف فقط بمجرد تعطل نظام التطوير الخاص بك مؤقتًا.

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

nikdojo استخدم link: للاعتماديات بدلاً من file: ، فهو يستخدم الروابط الرمزية. تم تقديمه في 0.26 .

بدلاً من ذلك ، ابدأ في استخدام مساحات العمل إذا كان لديك العديد من التبعيات بين المشاريع.

mtraynham Thx للتلميح ، حاولت العثور على أي معلومات abt link: Protocol في المستندات الرسمية ، ولكن يبدو أنها ليست موجودة. تجربة مساحات العمل الآن.

@ bestander btw كما تعلم ، لا يدعم رد الفعل الأصلي

هذا لم يحل أبدا أليس كذلك؟ يجب عليك استخدام linklocal (حزم NPM) لربط الحزم المحلية (والتي يجب أن تكون الطريقة القياسية التي يعمل بها الغزل عند استهلاك الحزم من نظام الملفات المحلي - باستخدام الوصلات أو الروابط الرمزية على Windows بدلاً من التخزين المؤقت). ثم يقوم yarn install بالكتابة فوق كل شيء بالأشياء القديمة من ذاكرة التخزين المؤقت وعليك البدء من جديد الارتباط مرة أخرى.

هل يمكن أن نكون رواد فضاء معماريين أقل وببساطة لا نخزن الحزم المحلية مؤقتًا؟ يبلغ عمر هذه المشكلة الآن 1.5 عامًا ، وقد سئمت من تشغيل yarn add ../<another-local-package> كل مرة أقوم فيها بتغيير شيء ما في another-local-package .

مرحباfungilation
لقد فتحت قضية أخرى ذات صلة: # 6037

لا يعمل
لقد وضعت في ملف App.js
console.log ("ها نحن هنا") ، ولم يتم إخراجها.
ثم قم بإزالة جميع الملفات ولا يزال يخرج من ذاكرة التخزين المؤقت.
كيف تتجنب هذا؟

لقد خذلتني الغزل حقًا في هذه القضية. لقد كان رائعًا لكل شيء آخر ، باستثناء هذا.

لقد كنت أحاول تثبيت إصدار جديد من الحزمة المحلية لأغراض الاختبار ، وما زلت في النهاية مع الحزمة القديمة بغض النظر عما أفعله.

لقد حاولت:

1. تنظيف ذاكرة التخزين المؤقت للغزل ( yarn cache clean package-name )
2. yarn add 'مع --force
3. إزالة node_modules/package-name و yarn add جي مرة أخرى
4. تحديث رقم الإصدار واسم الملف للحزمة المحلية ( لا يزال الغزل يثبت محتويات الإصدار القديم ، على الرغم من الإبلاغ عن تثبيت الإصدار الأحدث)
5. مجموعات من كل ما سبق

هذا أمر سخيف ، وقد قضيت ما يقرب من 4 ساعات من يومي في هذا الأمر.

نحن بحاجة إلى القدرة على تطوير وإعادة تثبيت الحزم المحلية . أنا أعتمد على الغزل لتثبيت ملف في مجلد .bin ، لذا فإن yarn link غير وارد.

@ Yarn Developers: هل أنت قادر على تثبيت حزمة محلية ، وإجراء تغييرات على تلك الحزمة المحلية ، ثم جعل التغييرات تنعكس عن طريق التثبيت مرة أخرى؟

gregjacobs لقد نجحت مع yarn install --force

jonathantorley لقد --force وما زالت لا تعمل مع الغزل 1.12.3

بالنسبة للآخرين الذين يواجهون هذه المشكلة: كان أحد الحلول التي استخدمتها بالفعل لجعل هذا يعمل هو زيادة رقم إصدار الحزمة التابعة. مزعج بعض الشيء ، وعليك أن تتذكر أن تفعل ذلك في كل تغيير (إلا إذا كان بإمكانك كتابته).

يجب ألا يطلب yarn هذا الحل عند تثبيت الحزم المحلية

أضفت yarn upgrade MY_PACKAGE_NAME في برنامج نصي preinstall ، وتمت ترقيته إلى أحدث إصدار NPM جيدًا. (ما زلت بحاجة إلى رفع إصدار NPM يدويًا).

يبدو أن yarn add file:PATH الآن دائمًا ما يقوم بترقية المحتوى الجديد الآن في الغزل 1.13.0.
لا يزال yarn install غير موجود.

leavesster لا يناسبني.

لا بد لي من إعادة تسمية tgz حتى يتم التحديث

جرب استخدام الأمر link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn add file:PATH لم يقم بترقية المحتوى الجديد لي. علاوة على ذلك ، لا يتم احترام الملفات الموجودة في package.json و .npmignore.

يعمل عليك تغيير إصدار الحزمة الخاصة بك.

إذا كنت تريد أن يحترم yarn add file:PATH الملفات في package.json و .npmignore ، فيجب عليك تشغيل yarn pack في تبعية الحزمة المحلية الخاصة بك ، ثم في المكان الذي تريد تثبيته فيه ، قم بتشغيل yarn add file:path-to-local-pacckage.tgz

جرب استخدام الأمر link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn link غير مخصص للإجابة على نفس المشكلة. ليس جيدًا إذا أراد شخص ما حزمة npm كما لو تم نشرها مع احترام الملفات الموجودة في package.json و .npmignore

leavesster لا يناسبني.

لا بد لي من إعادة تسمية tgz حتى يتم التحديث

ليس لدي أي tgz في الحزمة الخاصة بي التي أستخدم yarn add file: PACKAGE_PAH لإضافتها في المشروع الحالي. لدي فقط كود js في الحزمة الخاصة بي. ربما لا يزال tgz مخطئا؟

لم يعمل معي ايضا

@ bestander لماذا أغلقت هذه القضية؟ لا يزال الغزل يخزن الملفات المحلية وحزم tgz مؤقتًا. لا تعد مساحات العمل حلاً في بعض الحالات ، على سبيل المثال إذا كانت إحدى الحزم تحتوي على إصدارات معينة ، وكانت الحزمة الأخرى تحتوي على حزم devDeps نفسها كما في الأولى ، ولكن مع إصدارات أخرى ، وإذا قمت بربط حزمة بأخرى ، فقد تم كسر مشروعك .

لدي نفس المشكلة مثلgregjacobs. yarn cache clean package لم يساعد. لكنني اكتشفت أنه إذا قمت بتثبيت yarn add path/to/package.tgz ثم قمت باستبدال الأرشيف بآخر ، فيمكنك تثبيت إصدار جديد ببساطة قم بتغيير المسار مثل yarn add path/to/../to/package.tgz ، لذا فإن المسار المطلق هو نفسه ، ولكن بالنسبة للغزل ، يختلف الأمر .

لا أفهم أي مكان آخر لتخزين الحزم المخزنة مؤقتًا بواسطة مسار الدقة ، حتى yarn cache list --pattern package فارغ.

أعتقد أن المشكلة في مكان ما هنا https://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58 -L63

ماذا يحدث:

• من url path/to/package.tgz يولد تجزئة (لهذا السبب path/to/package.tgz و path/to/../to/package.tgz النتائج إلى تجزئات مختلفة)
• باستخدام هذا التجزئة ، يتم إنشاء دليل مؤقت للحزمة (مثل هذا /Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 )
• للتشغيل الأول ، isValidModuleDest بإرجاع false وكل شيء يسير بشكل صحيح
• حزم Tarball المستخرجة في هذا الدليل
• تم تثبيت ملفات من هذا الدليل في المشروع
• يمكنك تعديل تطوير مصادر المشروع وإنشاء / حزم حزمة tarball الجديدة بنفس الاسم والموقع الذي سبقه
• وحاولت تثبيت tarball جديد ، لكن التجزئة التي تم إنشاؤها هي نفسها كما كانت من قبل ولم يتم مسح الدليل المؤقت بعد التشغيل الأول
• لذلك في هذا الوقت isValidModuleDest return true
• وقم بتثبيت الإصدار القديم من الحزمة الخاصة بك
• تقوم بتشغيل yarn cache clean package ، لكن الدليل المؤقت يظل دون تغيير

bestander هل يمكننا ببساطة إزالة دليل temp هنا https://github.com/yarnpkg/yarn/blob/master/src/config.js#L431 ؟

في مواجهة نفس المشكلة ، تأخذ ذاكرة التخزين المؤقت الموجودة ضمن مجلد temp 10 غيغابايت بعد أن أعمل على pacakge المحلي ليوم واحد فقط!

هل يمكننا إعادة فتح هذه القضية؟ نحن نواجه نفس المشكلة. مشروعان يشيران إلى حزمة أخرى عبر ملف:. بعد بعض الإنشاءات في خادم CI / CD ، يبدأ مجلد ذاكرة التخزين المؤقت في شغل مساحة كبيرة.

أعتقد أن بروتوكول الارتباط هو أفضل حل لهذا ، الملف: // لا يعمل لأنه لا يزال يتطلب ذاكرة تخزين مؤقت نظيفة يدويًا وإجبار التثبيت

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

فقط اجعل اعتمادك شيئًا كهذا

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

alxtz هل يعمل بروتوكول الروابط مع الحزم في tgz؟

أعتقد أن بروتوكول الارتباط هو أفضل حل لهذا ، الملف: // لا يعمل لأنه لا يزال يتطلب ذاكرة تخزين مؤقت نظيفة يدويًا وإجبار التثبيت

# 2165 (تعليق)

فقط اجعل اعتمادك شيئًا كهذا

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

شكرًا على هذا ، هذا يكرر سلوك NPM الذي سيربط رمزًا لمراجع file:.. في node_modules . يبدو أنه غير موثق ، على الأقل ليس هنا حيث أتوقع أن أجده: https://yarnpkg.com/lang/en/docs/package-json/

للأسف ، لا يمكن استخدام link في جميع الحالات.

على سبيل المثال ، أحتاج إلى تبعية مشتركة / نظير من حزمة SDK الخاصة بي ، والتي عندما أقوم بإجراء تغييرات ، سأقوم بالربط للعمل المطور المحلي.
باستخدام link ، لا يدرك الغزل أن التبعية هي تبعية مشتركة / تبعية نظير ويستخدم الحزمة المحلية حيث يكون الارتباط الرمزي ، وهذا غير صحيح.

لقد كنت أستخدم yarn pack بجانب yarn add file:<path_to_packed_tgz> للتغلب على هذا.
بينما يمكنني الاستمرار في إعادة تسمية الحزمة في كل مرة أقوم بتعبئتها ولصقها في الريبو الخاص بي ، حتى لا يتم إنشاء نفس التجزئة ، وفقًا

قمت بتقسيم الريبو ووضعت فقرة إضافية في عبارة if لإيقاف عملية الغزل من تحميل حزمة .tgz محلية من ذاكرة التخزين المؤقت الخاصة بها إذا تم تحديدها باستخدام 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
}

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

ojboj في الوقت الحالي ، قد يساعد yalc حتى يحصل هذا على الإصلاح المناسب. لقد كان يعمل جيدًا بالنسبة لي لاختبار الحزم محليًا قبل النشر.

souporserious هذا بالضبط ما احتاجه / أردته ، شكرًا جزيلاً لك!

مجنون هذا لا يزال مشكلة بعد سنوات عديدة.

هل تم إصلاحه في [email protected]؟

wKich أعتقد ذلك! لم أختبرها شخصيًا ، لكن يبدو أنها تحل التنمية المحلية من خلال بروتوكول البوابة الجديد.

ما زلت أتلقى خطأ "فك الضغط في نفس الوجهة" باستخدام بروتوكول link: ، وهو يشير إلى دليل ذاكرة التخزين المؤقت ، لذلك يبدو لي أن الغزل لا يزال يخزن تبعيات link: مؤقتًا. أنا أشير إلى نسختين من نفس الحزمة المحلية ، تم نسخها في المجلد .deps/ لكل تطبيق يستخدمها - front-end و renderer في الخطأ أدناه. (لا يمكن الارتباط بالأصل لأسباب غير ذات صلة)

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.