لا أعتقد أن هذا خطأ. تمكنت من إعادة إظهار المشكلة ولكن كان الاختلاف

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

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

يجب أن أعترف أن هذا غير بديهي إلى حد ما ونحاول التوصل إلى حل جيد لذلك. يمكنك متابعة أو المساهمة في المناقشة على # 4147.

إذا كنت توافق على أن هذا ليس خطأ وأن رقم 4147 هو مكان جيد لمواصلة المناقشة ، فالرجاء إغلاق المشكلة :)

BYK شكرا

4147 ويبدو أن حصرا عن الحالة التي يكون فيها yarn.lock وpackage.json ليسوا على وفاق - في الواقع التحسين المرة الوحيدة التي يرد ذكرها في هذا التعليق: https://github.com/yarnpkg/yarn/issues/4147 #issuecomment -321894341 - وهذا التعليق يلامس المشكلة التي تهمني: تعديل الغزل لملف yarn.lock عندما لا يتم إجراء أي تغييرات على package.json .

يبدو لي أن الملف yarn.lock يجب أن يتغير فقط إذا تغيرت تبعياتي بطريقة ما. في الواقع ، حتى هذه اللحظة ، كنت أخبر مطوريي أنهم إذا لاحظوا تغييرًا في ملف yarn.lock ، فقد حان الوقت لتشغيل yarn install . مع العديد من الترقيات الأخيرة التي تم الإبلاغ عنها أنه بعد تلقي التغييرات الخاصة بي وتشغيلهم yarn install ، تم تغيير ملف القفل الخاص بهم (التحسين). هذا يجعل الوضع محيرًا - هل يجب عليهم إجراء التغيير؟ هل يجب أن أقوم بطريقة ما بتحسين ملف القفل مسبقًا (هل هذا ممكن)؟

يبدو أنني قد أضطر ، على المدى القصير ، إلى إضافة --frozen-lockfile true إلى .yarnrc في جميع عمليات إعادة الشراء الخاصة بي - لكنني لست معجبًا كبيرًا بهذا الحل لأنه يمنع سير العمل المذكور في # 4147 حيث تقوم بتحرير package.json ثم تشغيل yarn install .

هل النية أن أي طلب للغزل قد يؤدي إلى تعديل yarn.lock ؟

BYK أنا آسف لإزعاجك بشأن هذا لأنني أعلم أنك مشغول للغاية - لكني آمل أن أحصل على إجابة نهائية عن هذا. لقد تحول سير العمل الخاص بي لتوزيع تغييرات التبعية على فريقي إلى هذا:

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

يبدو أن هذا يقوم بتحديث ملف القفل بشكل صحيح (انظر # 4476) ، ثم تحسين ملف القفل بحيث لا يقوم زملائي بفريق بالتحقق من تغييرات ملف القفل.

هل فريقي يستخدم الغزل بشكل غير صحيح؟ هل يجب أن نتوقع تغيير ملف القفل مع كل أمر install ؟

artlogic IMHO ، يجب السماح لزملائك في الفريق بتسجيل تغييرات ملف القفل حتى لو كانت مجرد تحسينات. أتفق مع الفكرة القائلة بأن تحسين ملف القفل yarn install أمر غير بديهي ، ومع ذلك لا يزال شيئًا يمكن لكل مطور في فريقك الالتزام به بأمان. لا أفهم لماذا تريد منع ذلك.

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

إذا كنت لا تزال ترغب في فرض أن التثبيت لا يلمس ملف القفل ، فيجب عليك استخدام علامة frozen-lockfile :

 yarn add {blah}

قم بتسجيل الدخول إلى ملف القفل ، ثم سيستخدم مطور آخر:

   yarn install --frozen-lockfile

لا تضيف --frozen-lockfile إلى true في .yarnrc لأنه يمنعك من التحديث ، راجع: # ​​4570

إذا كنت ترغب في ترقية تبعياتك ، فقم بتشغيل:

 yarn upgrade

إذا كنت ترغب في ترقية تبعية واحدة فقط:

  yarn upgrade {blah}

يمكنك أيضًا تثبيت إصدار محدد من تبعية واحدة فقط:

  yarn install {blah}@1.5

وهذا يسمح بمزيد من الضبط الدقيق وتقليل الصداع على المدى الطويل.

@ k0pernikus - شكرًا على ردك المفصل. أولاً ، يجب أن أعتذر عن الخلط بين مشكلتين - # 4476 يقود بعض سير العمل الخاص بي. حقيقة أن yarn upgrade يبدو أنه مكسور إلى حد ما لا علاقة له بهذه المشكلة بالطبع.

بالنسبة لسير العمل ، لا أستطيع أن أتخيل أن فريقي هو الفريق الوحيد الذي يتولى فيه مطور واحد مسؤولية صيانة / اختبار التبعيات الجديدة بينما يعمل المطورون الآخرون على قاعدة التعليمات البرمجية. المشكلة الكبيرة التي أواجهها فيما حدث هو أنني سأقوم بتثبيت / اختبار التبعيات الجديدة ، وإخبار الجميع بتشغيل yarn install ثم الحصول على 4-5 أسئلة حول ما إذا كان يجب الالتزام بالتغيير yarn.lock . يبدو أنني سأكون في مكان أسوأ إذا قلت "إذا تغير ملف القفل ، فقم بإلزامه" لأنه في هذه المرحلة قد ينتهي بي الأمر إلى قفل الالتزام الذي يبدو مثل هذا:

• تم تغيير قفل الغزل (dev4)
• تم تغيير قفل الغزل (dev3)
• تم تغيير قفل الغزل (dev2)
• تم تغيير قفل الغزل (dev1)
• التبعيات المحدثة (أنا)

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

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

artlogic يمتلك فريقنا --install.pure-lockfile true في المشروع .yarnrc لهذا السبب بالضبط.

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

إذا تمكن شخص من فريق الغزل من تأكيد أن القصد هو أن yarn install يمكنه تغيير ملف القفل في كل عملية تشغيل (على الرغم من عدم وجود تغييرات في التبعيات) فسوف أغلق هذه المشكلة.

artlogic آسف على الرد المتأخر.

الشيء هو أنه __ متوقع__ أن yarn install قد يغير ملف القفل. أعلم أن هذا ليس مثاليًا ويحتاج إلى تواصل أفضل. أريد حقًا أن يكون لدي خيار افتراضي أفضل ولكن في هذه الأثناء ، أعتقد أن شيئًا مثل jboler اقترح مع ولكن ربما باستخدام --frozen-lockfile بدلاً من ذلك ، سيكون الحل الأفضل حتى نكتشف كيف يجب أن يتصرف الغزل في سيناريوهات مختلفة مثل سير العمل حيث يفضل الأشخاص ببساطة تحرير package.json لتحديث التبعيات بدلاً من استخدام yarn add إلخ.

BYK اتفقت مع artlogic . هذا السلوك محير للغاية:

المشكلة الكبيرة التي أواجهها فيما حدث هو أنني سأقوم بتثبيت / اختبار تبعيات جديدة ، وإخبار الجميع بتشغيل تثبيت الغزل ثم الحصول على 4-5 أسئلة حول ما إذا كان يجب الالتزام بـ yarn.lock المتغير.

يتكون فريقنا من حوالي 50 شخصًا يديرون yarn install كل يوم :(

vkrol ، يجب أن تكون قادرًا على إيداع ملف .yarnrc يحتوي على --install.frozen-lockfile true أو --install.pure-lockfile true لتجنب المشاكل حتى يغير Yarn سلوكه. هل سيساعد ذلك؟

سيساعدناBYK pure-lockfile ، لكن ليس frozen-lockfile . إذا فهمت بشكل صحيح ، فسيفشل yarn install مع ظهور خطأ إذا تم تمكين ملف التجميد. هذا السلوك غير مقبول على الإطلاق في حالتنا.

vkrol المفضل لدي هو frozen-lockfile لأنه لن يفشل إلا إذا كان ملف القفل الخاص بك يحتاج إلى التغيير ولم يكن ثابتًا. باستخدام pure-lockfile قد يكون لديك ملف قفل قريب من كونه عديم الفائدة أو غير دقيق للغاية ولكنك ما زلت لن تتعرض للفشل. سيستخدم الغزل ببساطة القرارات الداخلية التي يحسبها بسعادة. إذا كان جميع أعضاء فريقك يستخدمون نفس الإصدار بالضبط من Yarn ، فلا بأس بذلك. إذا لم يكن الأمر كذلك ، فقد يكون خطيرًا.

BYK ربما لا أفهم سلوك frozen-lockfile بشكل صحيح. هل يفشل عندما يكون ملف القفل متسقًا مع محتوى package.json ، لكن هناك حاجة إلى بعض التحسين الداخلي؟

vkrol لا يجب أن يفشل عندما يمكن تحسين الملف بشكل أكبر ولكنه يتوافق مع package.json ومتسق في حد ذاته. إذا لم يكن الأمر كذلك ، فهذا خطأ. حتى أن هناك اختبارًا لهذا: https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

BYK لم أكن أعرف عنها. سأحاول هذا الخيار ، شكرا! أعتقد أنه يجب توثيق هذه الحقيقة في مكان ما.

BYK

لا ينبغي أن يفشل عندما يمكن تحسين الملف بشكل أكبر ولكنه يتوافق مع package.json ومتسق في حد ذاته.

لقد وجدت بعض الجوانب السلبية لاستخدام هذا العلم. إذا كان من الممكن تحسين yarn.lock من الاستدعاءات المتكررة لهذا الأمر yarn install --frozen-lockfile لم يتم تحسينها عبر فحص "سلامة" بدون هذه العلامة. هل هذا خطأ؟ هل أحتاج إلى إنشاء إصدار منفصل؟

BYK شكرا لردكم. بالنسبة لمشاريع فريقي ، نستخدم الآن frozen-lockfile وتعمل الأمور (نسبيًا) بشكل جيد. ومع ذلك ، لا تزال هذه المسألة مقلقة بالنسبة لي. على وجه التحديد ، يتم إجراء التحسينات غير الضرورية على ملف القفل عند تشغيل yarn install .

إليك أوضح مثال يمكنني تقديمه عن المكان الذي يتسبب فيه هذا السلوك في حدوث مشكلات:

1. أقوم بإضافة تبعية جديدة باستخدام yarn add [blah] وأقوم بتحديث package.json و yarn.lock .
2. يقوم المساهمون في الحزمة بسحب التغييرات ولاحظوا أنه تم تحديث yarn.lock ، وبالتالي قم بتشغيل yarn install .
3. في بعض الحالات ، ينتهي هؤلاء المساهمون yarn.lock بعد التثبيت. ماذا يجب أن يفعلوا في هذه الحالة؟ هل هو سباق لمعرفة من يمكنه تقديم طلب السحب أولاً؟

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

1. قم بتوجيه أي مشروع يدير التبعيات مركزيًا لإضافة --install.frozen-lockfile true إلى ملف .yarnrc . من المحتمل أن يكون هذا عددًا كبيرًا من المشاريع - أعتقد أن معظم حزم NPM.
2. قم بتوفير مفتاح لفرض الغزل لتحسين ملف القفل أثناء مرحلة الإضافة ، على سبيل المثال yarn add --optimize [blah] . ثم قم بتوجيه المشرفين على الحزم لاستخدام هذا المفتاح دائمًا.
3. عدم السماح للغزل بتحسين yarn.lock أثناء مرحلة التثبيت ما لم يظهر أنه تم تحديث package.json .

أنا أدافع عن الخيار 3 ، لكن يمكنني أن أرى أن الخيار 2 هو خيار معقول أيضًا.

شكرا على وقتك!

تعجبني فكرة أن yarn install لا يقوم بتحديث ملف yarn.lock ولكن بدلاً من ذلك يرسل تحذيرًا يقول "ملف yarn.lock الخاص بك قديم ، قم بتشغيل yarn blah إلى تحديثه الآن`.

BYK لماذا ~ لا يطبق الغزل تحسينات على yarn.lock على yarn install بدلاً من تشغيل add / upgrade ؟

تحرير: إصلاح الخطأ المطبعي

@ spencer-brown: بناءً على ما رأيته ، فإنه في الواقع يطبق تحسينات على التثبيت - وهذا ما أجده مشكلة

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

artlogic عفوا ، خطأ مطبعي :) - تعليقي يجب أن يقول "يفعل" ؛ تم تحريره.

نستخدم الملحن كثيرًا ولا يلمس ملف القفل composer install أبدًا.

composer update أو composer require (ما يعادل yarn add ) لإجراء أي تغييرات أو تحسينات على ملف القفل.

في سنوات عديدة ، لم يكن علينا أبدًا القلق بشأن السلوك الغامض لـ composer install .

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

نستخدم الملحن كثيرًا ولا يلمس ملف القفل composer install أبدًا.

composer update أو composer require (ما يعادل yarn add ) لإجراء أي تغييرات أو تحسينات على ملف القفل.

في سنوات عديدة ، لم يكن علينا أبدًا القلق بشأن السلوك الغامض لـ composer install .

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

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

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

أنا أميل إلى الاعتقاد بأن yarn install --pure-lockfile يجب أن يكون هو الخيار الافتراضي ، ويمكن أن يكون هناك خيار --fix-my-dev-process-inconsistencies-for-me-magically للحصول على السلوك الحالي.

ryancastle --pure-lockfile لن يخبرك أن التحديث لملف القفل الخاص بك. إنها فقط لا تولد واحدة. قد لا يزال هذا يؤدي إلى سلوك غير متوقع. --frozen-lockfile سيفشل إذا كان التحديث مطلوبًا.

لقد كنت أعمل مع --install.frozen-lockfile true في .yarnrc الخاص بي لفترة من الوقت الآن ويبدو أنه يعمل بطريقة عاقلة. الحيلة هي إنشاء yarn.lock المبدئي للريبو دون تفعيل هذه العلامة. بمجرد إنشائه ، لا يمكن لعمليات التثبيت تغيير yarn.lock ، لكن يمكن للتحديثات تغييرها. بمجرد أن بدأت في استخدام سير العمل هذا ، انخفض عدد التغييرات العرضية إلى yarn.lock إلى الصفر.

artlogic Sidenote: اعتدت أن أحصل على frozen-lockfile true في .yarnrc أيضًا ، والآن أقوم بتطبيقه فقط على خادم الإنشاء ، حيث واجهتنا مشكلات كانت تغييرات مقصودة على yarn.lock لم يتم إنشاء package.json إلى yarn.lock ، لأن أحد المطورين قام يدويًا بتحرير package.json أو استخدم npm لإضافة التبعيات.

انظر: https://github.com/yarnpkg/yarn/issues/4570

حالة استخدام @ k0pernikus هي السبب في أننا لم نجعل --frozen-lockfile الافتراضي مع yarn install . أنا بصراحة لا أعرف ما هو الحل الوسط الجيد دون إعاقة الأشخاص الذين يقومون بتحرير package.json ثم تشغيل yarn install لتحديث ملف القفل. لقد اقترحت علامة أو أمرًا جديدًا مثل yarn sync لكن الفكرة تحتاج إلى توضيح ومن ثم الحكم عليها من قبل المجتمع قبل تنفيذها.

علاوة على ذلك ، سيكون هذا تغييرًا جذريًا ، لذا سيتطلب Yarn 2.x :)

علم أو أمر جديد مثل مزامنة الغزل

يبدو جيدا بالنسبة لي 👍. و yarn install قد يُظهر إشعارًا بأن "package.json و yarn.lock غير متزامنتين. شغّل" yarn sync "لتحديث ملف القفل"

أنا بصراحة لا أعرف ما هو الحل الوسط الجيد دون إعاقة الأشخاص الذين يقومون بتحرير package.json ثم تشغيل تثبيت الغزل لتحديث ملف القفل.

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

لقد اقترحت علمًا أو أمرًا جديدًا مثل مزامنة الغزل ولكن الفكرة تحتاج إلى تجسيد ثم الحكم عليها من قبل المجتمع قبل تنفيذها.

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

هذا ما أود رؤيته:

• ينشئ yarn install بدون yarn.lock yarn.lock .
• yarn install مع yarn.lock لا يعدله. إذا وجدت أن هناك تناقضًا بين yarn.lock و package.json ، فسيتم إرجاع خطأ (مثل
• yarn sync إعادة مزامنة yarn install -s ) yarn.lock للمزامنة مع package.json .

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

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

نفس الشعور هنا. اعتقدت أن هذا هو السبب المحدد لبقاء هذه المشكلة مفتوحة. نظرًا لأنه تتم مناقشة "المزامنة" في رقم 4147

لهذا السبب بحثت عن هذه المشكلة في المقام الأول.

هل يجب دمج هذا و # 4147؟

BYK أعتقد أنه يمكن دمج كل ما تمت مناقشته هنا تقريبًا مع # 4147. كما قلت من قبل ، أعتقد أن الشيء الوحيد الذي لا يزال يقلقني هو "التحسينات" التي يجريها yarn install على yarn.lock حتى في حالة عدم حدوث تغييرات على package.json .

فكرتي هي أنه يجب تعطيل هذه التحسينات باعتبارها نقطة توقف في طريق غزل 2.0. لا أعتقد أن هذا سيكون تغييرًا مفاجئًا.

أوافق 100٪ مع artlogic .

كنت أقوم بإعداد CircleCI واستمر بناؤه في الفشل وتتبعته طوال الطريق وصولاً إلى مشكلة التخزين المؤقت مع yarn.lock . قادمًا من ريلز ، أتوقع أن يتم قفل ملف القفل بواسطة أمر التثبيت.

هذا هو ما تم اقتراحه لفحص ذاكرة التخزين المؤقت على CircleCI: https://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

لن ينجح هذا أبدًا لأن yarn.lock يمكن أن يتغير ، عندما لا ينبغي ذلك.

لمعلوماتك ، على الغزل 1.10.1 تحت macOS 10.13.6 ، جربت للتو تحفيز خطأ OP ووجدت أن yarn.lock لم يتغير. بمعنى آخر عندما حاولت:

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

لذلك ، عند استخدام الغزل 1.10.1 ، لم يتغير yarn install yarn.lock ، كما حدث لـ OP عند استخدام الغزل 1.0.1. (أنا أعتبر هذا أمرًا جيدًا ، كما أعتقد أن OP.)

dtgriscom من الرائع أن المشكلة لم تعد تحدث في كوردوفا! أتساءل عما إذا كان قد تم إصلاحه بالكامل أو ما إذا كان الغزل لا يزال يحاول تحسين ملف القفل عند التثبيت؟

سيكون من الجيد معرفة ذلك ، أليس كذلك؟ لقد لاحظت أن المشكلة كانت خاصة بالحزمة ؛ من المنطقي أنه قد يكون خاصًا بالإصدار أيضًا. (لم أسمع أبدًا أي تبرير لـ "نريد تغيير شيء لا ينبغي تغييره" ؛ بخلاف "نحن نحسن" ...)

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

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

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

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

yarn install

قم بتثبيت جميع التبعيات المدرجة ضمن package.json في المجلد node_modules المحلي.

يتم استخدام الملف yarn.lock النحو التالي:

• إذا كان yarn.lock موجودًا وكان كافياً لتلبية جميع التبعيات المدرجة في package.json ، يتم تثبيت الإصدارات الدقيقة المسجلة في yarn.lock ، و yarn.lock لن تتغير . لن يتحقق الغزل من وجود إصدارات أحدث.
• إذا كان yarn.lock غائبًا ، أو لم يكن كافياً لتلبية جميع التبعيات المدرجة في package.json (على سبيل المثال ، إذا قمت بإضافة تبعية يدويًا إلى package.json ) ، يبحث Yarn عن أحدث الإصدارات المتاحة التي تلبي القيود في package.json . النتائج مكتوبة على yarn.lock .

إذا كنت تريد التأكد من عدم تحديث yarn.lock ، فاستخدم --frozen-lockfile .

هل التوثيق خاطئ لأن هناك هذه التحسينات التي يمكن أن تحدث المذكورة أعلاه أم أن هذا خطأ يجب أخذه في الاعتبار في الوقت الحالي؟

ملاحظة. لا يزال يحدث ، ولا يفشل yarn --frozen-lockfile عندما يحدث ذلك.

أنا حاليًا باستخدام --frozen-lockfile في ملف .yarnrc ، والذي يمنع بشكل فعال الغزل من تعديل ملف yarn.lock عند تشغيل yarn install على أجهزة مختلفة. ولكن هذا أيضًا يمنع yarn add blahblah من تعديل yarn.lock الخاص بي. هل هذا هو السلوك الصحيح أم أنني أفتقد شيئًا؟ لقد قرأت من خلال الموضوع بأكمله ويبدو لي أن --frozen-lockfile هو الأسلوب الموصى به في الوقت الحالي؟

konekoya نعم ، أنت محق في أنك يجب أن تستخدمه حاليًا

yarn install --frozen-lockfile

ولا يمكن الاعتماد على الإعداد في .yarnrc لأنه سيمنع تحديث yarn.lock الخاص بك على الإطلاق.

اعتمادًا على المحتوى الخاص بك من .npmrc و .yarnrc قد تتمكن من استخدام

yarn install --no-default-rc {dependency}

لكنني لن أعتمد على ذلك (لأنه سيتعطل بمجرد أن يكون لديك إعدادات أخرى في ملفات rc الخاصة بك.)

انظر تعليقي والقضية ذات الصلة: # 4570 ، esp. استنتاجي .

شكرا لتوضيح ذلك حتى @ k0pernikus. انت صنعت يومي :)

BYK لماذا يطبق الغزل التحسينات على yarn.lock على yarn install بدلاً من تشغيل add / upgrade ؟

أعتقد أن تعليق @ spencer-brown هنا هو مفتاح "إصلاح" هذه المشكلة. لقد اختبرت نفسي للتو وتشغيل yarn upgrade ثم yarn قيل لي "محدّث بالفعل.". لذلك حذفت node_modules وقمت بتشغيل yarn مما أدى بعد ذلك إلى ملف القفل "المحسن" الذي كان سينتهي به المطورون الآخرون في مشروعي إذا قمت بدفع الملف الذي حصلت عليه من yarn upgrade .

الآن إذا كان yarn upgrade (و yarn add ) سيشغلون نفس التحسين مثل yarn install فلن نواجه هذه المشكلة في المقام الأول. كان هناك الكثير من الحديث عن عدم الرغبة في كسر أي وظيفة موجودة ولا أرى تشغيل التحسين بعد yarn upgrade و yarn add ككسر أي شيء - فقط جعله أبطأ قليلاً.

كحل بديل ، أفكر في توجيه جميع مطورينا لحذف node_modules كلما احتاجوا إلى تحديث ملف القفل لفرض "التحسين" قبل دفع ملفات القفل للآخرين. أو ربما يمكنهم تشغيل yarn upgrade && yarn prune - ربما هذا سيفي بالغرض؟

كحل بديل ، أفكر في توجيه جميع مطورينا لحذف node_modules كلما احتاجوا إلى تحديث ملف القفل لفرض "التحسين" قبل دفع ملفات القفل للآخرين. أو ربما يمكنهم تشغيل yarn upgrade && yarn prune - ربما سيفي ذلك بالغرض

تحديث: لا يمكنك تشغيل prune يدويًا ، ستحصل فقط على هذه الرسالة: _ "أمر prune ليس ضروريًا. yarn install سيقلل الحزم الغريبة" ._ وبما أنه لا يمكنك تشغيل التثبيت لأنك هي _ "محدثة بالفعل" _ أعتقد أننا سنقوم بحذف node_modules ثم تشغيل yarn لإجراء التقليم.

بالنسبة لي ، فإن أكبر نقطة بيع فردية مقابل yarn هي سلوك ملف قفل يمكن التنبؤ به وموثوق به. يعطيني تغيير ملف القفل على yarn install قلقًا حقيقيًا.

بالنسبة لي ، فإن أكبر نقطة بيع فردية مقابل yarn هي سلوك ملف قفل يمكن التنبؤ به وموثوق به. يعطيني تغيير ملف القفل على yarn install قلقًا حقيقيًا.

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

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

لقد فوجئت للتو بهذا السلوك ، عند الانتقال من Node.js 13 إلى 14 ، تغيرت جميع ملفات yarn.lock عند إجراء yarn install وكنت أتساءل لماذا ...

أعتقد أن التصرف المناسب هو إرسال تحذير إذا _optimizing_ الملف yarn.lock بأي طريقة.