Yarn: هل يجب أن أضع yarn.lock في .gitignore؟

يجب عليك إضافة yarn.lock إلى git الخاص بك ، لا تتجاهلها.

راجع https://yarnpkg.com/en/docs/migrating-from-npm

عند تشغيل yarn أو yarn add <package> ، سينشئ Yarn ملف yarn.lock داخل الدليل الجذر لحزمتك. لا تحتاج إلى قراءة أو فهم هذا الملف - فقط قم بفحصه في التحكم بالمصادر . عندما يبدأ الأشخاص الآخرون في استخدام Yarn بدلاً من npm ، سيضمن ملف yarn.lock حصولهم على نفس التبعيات تمامًا كما لديك.

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

هل هذا صحيح؟

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

أيضًا ، إذا كان لديك سجل npm مصدق مسبقًا ، على سبيل المثال myget أي وكلاء لـ npm ، فسيكون لدى yarn.lock روابط مسبقة المصادقة للحزم ، وهو انتهاك أمني رئيسي 🎉
يجب توثيق هذا في مكان ما بخط كبير.

Pfeifenjoy ماذا لو قمت بالربط
باستخدام git ، يمكنك الوصول إلى الريبو باستخدام مفتاح النشر (عبر ssh)

beenotung لست من

كما أن التبعية التي أشير إليها ستحصل (وليس فقط مشاريعي الخاصة) على عنوان مختلف ، لأنها محفوظة في حسابي المحلي في sinopia. سيكون مملًا جدًا الإشارة إلى جميع وحدات العقدة التي تعتمد عليها مشاريعي في git.
علاوة على ذلك ، من الأسهل إزالة ملف yarn.lock.

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

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

thisolivier تبدو معقولة

مجرد مذكرة.
بسبب https://github.com/yarnpkg/yarn/issues/3330 ، إذا كنت تعيش في الصين أو منطقة محظورة أخرى ، وقمت ببناء الوحدة النمطية الخاصة بك مع سجل آخر (eq taobao) ، يجب عليك إضافة yarn.lock إلى .gitignore واكتب package-lock = false إلى .npmrc.

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

كما أنه يجعل التزاماتك قبيحة حقًا.

لا أتفق مع التعليق الأكثر تصويتًا هنا:

• إذا كان المشروع يستخدم npm ، فقم بالتزام package-lock.json في الريبو و gitignore yarn.lock
• إذا كان المشروع يستخدم الغزل ، فقم بالتزام package-lock.json yarn.lock في الريبو و gitignore package-lock.json

وهذا هو، يجب أن _not_ دائما ارتكاب yarn.lock إلى الريبو، والسؤال الجواب OP، ونعم قد ترغب في إضافته إلى .gitignore .

عندما يبدأ الأشخاص الآخرون في استخدام Yarn بدلاً من npm ، سيضمن ملف yarn.lock حصولهم على نفس التبعيات تمامًا كما لديك

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

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

كما ذكر Pfeifenjoy أعلاه:

لدي سجل npm مخصص. أنا أستخدم هذا التسجيل بشكل أساسي لمشاريع أخرى حيث لدي وحدات خاصة

ولكن عندما أقوم بدفع مشروع عام إلى مستودع git ، والذي يحتوي فقط على تبعيات عامة ، فإن yarn.lock لديه روابط خاطئة بالتبعية وسيفشل نظام CI الخاص بي في بناء المشروع.

^ شيء آخر ، حتى عند حلها محليًا ، يجب عليك دمج الحل في yaml أو أي تكوين لـ CI وفي أي مكان آخر تقوم فيه بتدوير التطبيق - نوع من المنطق الذي يمكنه معرفة وقت استخدام التسجيل والأمر - يبدو مزعجًا وغير ضروري

شيء آخر - إذا شجعت الجميع على الالتزام دائمًا بـ yarn.lock في الريبو ولم يتجاهلها أبدًا ، فسيبدأ المطورون في استخدام الغزل في الريبو الذي يعتمد بالفعل بشكل كبير على npm. حتى في الحالات التي يعمل فيها بشكل جيد ، سيكون هناك زيادات في ملفي القفل ، وسيفتح ذلك الباب أمام جحيم التبعية. وأنت تعلم أن بعض المطورين سيلتزمون yarn.lock 25 ألف سطر