Yarn: اجعل "--pure-lockfile" افتراضيًا لـ "التثبيت"

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

هناك حالة لـ yarn install لإنشاء ملف قفل إذا لم يكن موجودًا ، أي عندما يقوم شخص ما بتحويل مشروع لاستخدام yarn ، لكن الأساس المنطقي لكتابته دائمًا غير واضح. أتفق مع رأي bestander بأن الإجراءات المتغيرة فقط هي التي يجب أن تُحدِّث ملف القفل افتراضيًا ، على سبيل المثال add/upgrade/remove .

هل يجب أن تكون هناك طريقة لتعديل ملف القفل بدون add/remove/upgrade ex: في السيناريو عندما تقوم بترقية Yarn ويستخدم إصدار lockfile جديد؟

أفترض أنه يمكن عكس الخيار

yarn install --save-lockfile

في 17 أكتوبر 2016 الساعة 18:53 ، كتب James Ide [email protected] :

هل يجب أن تكون هناك طريقة لتعديل ملف القفل بدون إضافة / إزالة / ترقية
على سبيل المثال: في السيناريو عندما تقوم بترقية Yarn ويستخدم ملف قفل جديد
إصدار؟

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

أنا أيضا في حيرة من هذا. ما هو سبب السلوك الافتراضي الحالي؟

آفاق ، لم تكن هناك أسباب قوية للسلوك الافتراضي.
الفكرة ، كما أفترض ، هي الحفاظ على "دائمة الخضرة" ملفات الناس lockfiles.

راجع للشغل العلاقات العامة هو موضع ترحيب

أعتقد أن السبب في ذلك هو أن الغزل تم تصميمه في الأصل باستخدام أمر واحد install والذي تم تقسيمه إلى install/add/upgrade

لذا ، للتحقق مما إذا كنت أفهم هذا بشكل صحيح:

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

شكرا على الشرح!

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

@ kittens ألا يجب تحديث ملف القفل إلا عند إضافة / إزالة / ترقية أي حزم؟ يجب أن يقوم هؤلاء دائمًا بترقية ملف القفل ، بالإضافة إلى التثبيت الأولي.

تكمن المشكلة في أنه إذا كان ملف القفل نقيًا افتراضيًا ، فسينسى الأشخاص تحديثه لأنه سيكون أمرًا منفصلاً

تعتمد هذه المشكلة على ما تعتبره الهدف الرئيسي لمدير الحزم.

في رأيي ، أحد الأدوار التي يقوم بها مدير الحزم هو تسهيل البدء في تطوير المشروع قدر الإمكان. يجب أن تحصل على yarn install البسيط كل الحزم التي تحتاجها لبدء التطوير ، دون أي التباس.

مع npm ، كان لدي العديد من حالات انضمام المطورين إلى مشروع ، فقط لأجد أن المشروع لا يعمل على أجهزتهم. حدثت هذه الحالات بسبب التبعيات العابرة التي تصطدم بالإصدارات مع التغييرات المعطلة أو ببساطة لا تتبع semver. كنت آمل أن يحل yarn هذه المشكلات ، ولكن إذا كانت الوجبات الجاهزة هي أن جميع المطورين في المشروع يجب أن يديروا yarn install --pure-lockfile ليكونوا متأكدين بنسبة 100٪ من أن المشروع سوف يبنى ، فهذا ليس كذلك القضية.

دور آخر لمدير الحزم هو إعطاء المشاريع السيطرة على تبعياتها. إذا تم جعله نقيًا افتراضيًا ، فيمكن للمطورين إلقاء نظرة على yarn outdated لرؤية الإصدارات القديمة ثم مراجعة ملاحظات التغيير ، وتجنب أي تغييرات معطلة. هذا من شأنه أن يمنح المطورين تحكمًا كاملاً في الإصدارات ذات النتوءات فقط في إطار زمني محدد للإصدار بدلاً من منع المطورين من القيام بـ git commit -a لتجنب ارتباطات ملف القفل العرضي.

أنا أتفق مع كل ما يقوله esphen . أنا مندهش من أن السلوك النقي ليس هو الوضع الافتراضي في الغزل - اعتقدت أن هذا النوع من الاتساق هو الفائدة الرئيسية التي يتمتع بها الغزل على NPM. يجب أن يكون هذا هو السبب الأكثر إقناعًا للتبديل من NPM بالطريقة التي أراها.

فاجأنا تمامًا بتعطل الإنشاء بعد أن بدأنا في استخدام yarn لبضعة أيام. اعتقدت بصدق أن --pure-lockfile هو السلوك الافتراضي بعد قراءة الكثير من الوثائق وحول كيف أنها أفضل من npm باستخدام shrinkwrap. الرجاء جعل الافتراضي :)

ide تخيل سيناريو حيث يقوم شخص ما باستخدام npm فقط ويقوم بتحديث package.json ، كيف سيتم تحديث yarn.lock ؟

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

مزيد من المعلومات حول ما سبق: يحتوي بناؤنا على قهوة من جيثب كاعتماد فرعي. دفع coffeescript بعض الالتزامات وحصلنا على yarn.lock في عملية الإنشاء لدينا من تشغيل yarn install :

diff --git a/foo/yarn.lock b/foo/yarn.lock
index ec667fa..bb1f6ae 100644
--- a/foo/yarn.lock
+++ b/foo/yarn.lock
@@ -930,9 +930,9 @@ code-point-at@^1.0.0:
   version "1.6.3"
   resolved "https://registry.yarnpkg.com/coffee-script/-/coffee-script-1.6.3.tgz#6355d32cf1b04cdff6b484e5e711782b2f0c39be"

-"coffee-script<strong i="8">@github</strong>:jashkenas/coffeescript":
+coffee-script@jashkenas/coffeescript:
   version "1.11.1"
-  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/887052de079b2f0af9f080031a00bb7544eaca08"
+  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/0d132318ce8f7116a436d97db1f2a5c8b1dedf28"

 [email protected]:
   version "0.3.0"

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

أرى أن yarn install هو الأمر الذي يبني node_modules لي.
إنه عكس yarn add و yarn remove اللذان يعدلان package.json و yarn.lock و cleanup node_modules.
مقابل add و remove أقوم بتشغيل install 100 مرة في كثير من الأحيان خاصة في CI حيث لا أتوقع أبدًا حدوث آثار جانبية.

أمثلة عندما لا أتوقع أن تتغير الأشياء:

1. أنا على Yarn 0.15.0 ، زملائي في فريق Yarn 0.16.0.
   نظرًا لأن 0.16.0 أضافت مسافات بين الإدخالات في yarn.lock في كل مرة أقوم بتشغيل yarn install مقابل yarn.lock الذي تم إنشاؤه بواسطة زملائي في فريقي ، أحصل على ملف yarn.lock المعدل الذي أحتاج إلى تذكر عدم الالتزام به.
   والعكس صحيح.
2. تعتمد أدوات البناء الأخرى الخاصة بي على yarn.lock باعتباره "مصدر الحقيقة" لحالة node_modules. إذا تغيرت بشكل غير متوقع سأحصل على اللا حتمية في بنياتي

@ kittens

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

تخيل سيناريو يقوم فيه شخص ما باستخدام npm والتحديثات package.json ، كيف سيتم تحديث yarn.lock؟

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

يجب ألا يؤدي تثبيت الخيوط +1 إلى تغيير قفل الغزل

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

لست قلقًا بشأن تحديث ملف القفل. من الناحية المثالية ، يقوم برنامج Greenkeeper بذلك عند تغيير deps ويمكننا دمج تغيير ملف القفل بعد ذلك.

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

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

بمجرد قيامك بتعديل package.json يدويًا ، فإن التوقع في كل من Yarn و npm هو أنه عند تشغيل تثبيت آخر له _syncs_ مع package.json . بهذا المعنى ، يمكن إعادة تسمية yarn sync yarn install تقريبًا yarn sync .

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

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

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

لا يعني استخدام --pure-lockfile افتراضيًا أن الغزل لا ينتج عنه نتائج متسقة وموثوقة. نفس package.json سينتج عنه نفس yarn.lock والذي سينتج عنه نفس node_modules 100٪ من الوقت.

عند تحديث ملف package.json الخاص بك yarn.lock تحديثات الملف ثم تحديثات node_modules . هذا ترتيب طبيعي جدًا للأشياء ويجب أن نحافظ عليه على هذا النحو

فيما يتعلق بقدرة CI على الحصول على تبعيات مختلفة عندما تقوم بتحديث package.json ولكنك لم تقم بتشغيل yarn install لمزامنة كل شيء وأنا متأكد من أن شخصًا ما سيطرحه (على الرغم من أنني لا أرى ذلك مشكلة) - لقد تحدثت أنا والآخرون إلى أدوات CI المختلفة حول دمج Yarn ، يمكننا بسهولة الضغط عليهم لاستخدام --pure-lockfile افتراضيًا إذا رأى الناس أنها مشكلة كبيرة.

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

thejameskyle سأكون ممتنًا لو

1. المطور لديه package.json والذي يحتوي على تبعية "foo": "^1.0.0"
2. يدير المطور yarn install . الحزمة foo هي الإصدار الحالي من 1.0.0 ، لذا فإنها تنشئ ملف yarn.lock والذي يتم قفله في [email protected]
3. يضيف المطور yarn.lock إلى Git.
4. يقوم المطور بإجراء اختبارات الوحدة على نسخته المحلية من الريبو ، كل شيء يعمل بشكل جيد.
5. يدفع المطور الريبو إلى CI (مثل Travis).
6. يتم تشغيل CI yarn install ، ولكن تم تحديث foo الآن إلى الإصدار 1.1.0 ، لذلك يقوم Yarn بتثبيت [email protected] واستبدال yarn.lock بالإصدار الجديد من foo
7. تعطل CI لأن foo حدث تغيير فاصل في الإصدار 1.1.0

إليك موقف مشابه:

1. المطور لديه package.json الذي يحتوي على تبعية "foo": "^1.0.0" ، مقفلة كـ [email protected] ، و yarn.lock يتم حفظها في Git.
2. تعمل اختبارات الوحدة بشكل جيد على النسخة المحلية للمطور من الريبو.
3. يقوم أحد المساهمين باستنساخ الريبو بقصد إجراء تعديل + طلب سحب.
4. عندما يقوم المساهم بتشغيل yarn install ، يحصل على الإصدار [email protected] والذي يتسبب في تحديث yarn.lock .
5. الآن تم كسر بنية المساهم لأن foo حدث تغيير جذري في الإصدار 1.1.0

أعتقد أن هذا هو نوع المواقف التي يقلق معظم الناس بشأنها.

حتى إذا كنت يمكن توضيح أن السلوك الحالي من yarn install ليس لديها المشاكل المذكورة أعلاه، وأعتقد أن من شأنه أن يزيل معظم مخاوفنا. : +1:

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

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

ولكن لديه السلوك السيئ إذا تم تثبيت التبعية من جيثب ، كما ذكرت أعلاه

adamchainz يجب إصلاح ذلك بشكل منفصل ، يمكننا بسهولة قفله عند الالتزام

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

thejameskyle : لست متأكدًا من أنني أفهم لماذا هذا ليس سيناريو حقيقي. هل يمكنك أن تشرح بالتفصيل من فضلك؟

تخيل وظيفة memoize حيث يكون الإدخال package.json والمخرج هو yarn.lock .

1. في المرة الأولى التي تقوم فيها بتمرير package.json ، يتم إنشاء yarn.lock وتخزين النتيجة مؤقتًا.
2. في المرة التالية التي تقوم فيها بتشغيل _the نفس _ package.json ستكون النتيجة متطابقة تمامًا لأنها مخزنة مؤقتًا.
3. عندما تقوم بتغيير package.json فقد ألغيت ذاكرة التخزين المؤقت والآن سيتم إعادة حساب yarn.lock .

ما نتحدث عنه الآن هو التخلص من # 3 وبدلاً من ذلك نتعامل مع yarn.lock كما لو لم يتم إبطالها بواسطة التغيير package.json . وهو أمر غريب حقًا بالنسبة لوظيفة الذاكرة ، وسيكون سلوكًا غريبًا حقًا بالنسبة لـ Yarn.

ما يحدث للحزمة من حيث الالتزامات والإصدارات الجديدة _يجب_ أن تكون غير ذات صلة (إذا كان لدينا خطأ في التزامات git ، فعلينا إصلاح ذلك بشكل منفصل ، لكنه لا علاقة له بهذه المشكلة).

إنه أكثر تعقيدًا مما كنت أفكر فيه (يتم "حفظ" كل إصدار حزمة بشكل فعال بشكل فردي ، وتغيير إصدار حزمة واحدة لا يبطل الباقي) ، ولكن نأمل الآن أن يفهم الجميع هذه النقطة.

thejameskyle : من أجل الوضوح (والفضول) ، لنفترض أن لدي مشروعًا بملف yarn.lock ، وقام شخص ما بسحب المستودع. بدون تشغيل yarn install أو npm install ، يضيف هذا الشخص تبعية جديدة إلى الملف package.json ثم يقوم بتشغيل yarn install . هل سيتم تجاهل ملف yarn.lock تمامًا في هذه الحالة؟

هناك مجموعة من الأشياء المختلفة التي تحدث هنا والتي أردت أن أحاول كشفها (لا يقصد التورية).

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

من تقرير الخطأ الأصلي.

يُفقد الاتساق عند تعديل ملف القفل وفقًا للبيئة (إصدار الغزل المثبت حاليًا).
ما هو السلوك المتوقع؟
لا تكتب yarn.lock أو package.json عند القيام بتثبيت الغزل.
لتحديث yarn.lock ، استخدم ترقية الغزل

لنكون أكثر دقة ، فإن الدلالات المتوقعة ، في رأيي ، هي:

• إذا لم يتغير package.json منذ آخر مرة تغير فيها yarn.lock ، فإن yarn.lock هو مصدر الحقيقة ويجب عدم تحديثه.
• إذا تغير package.json منذ آخر مرة ، تغير yarn.lock ، قم بتحديث yarn.lock حتى يرضي package.json وتحديث node_modules .
• إذا تم تشغيل yarn update ، فأعد حل جميع التبعيات واحصل على أحدث إصدار من كل شيء يفي بـ package.json .

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

إلى الحد الذي لا يكون فيه هذا هو السلوك الحالي للغزل ، أعتقد أن هذا سيكون خطأ.

كتب esphen :

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

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

أتفق مع رأي bestander بأن الإجراءات المتغيرة فقط هي التي يجب أن تُحدِّث ملف القفل افتراضيًا ، أي إضافة / ترقية / إزالة.

المشكلة الرئيسية هنا هي ما إذا كان التغيير في package.json سيؤدي إلى تحديث yarn.lock . في رأيي ، إذا كان التغيير إلى package.json غير راضٍ عن yarn.lock ، يجب تحديث yarn.lock .

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

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

@ Guuz قال:

لذا ، للتحقق مما إذا كنت أفهم هذا بشكل صحيح:
يقوم الغزل بتثبيت جميع التبعيات ويقوم أيضًا بتعديل ملف القفل. على خادم CI ، يجب عليك استخدام تثبيت الغزل --pure-lockfile؟

يردد هذا السؤال صدى شعور قلة من الناس في هذا الموضوع.

تحمل علامة الشحن --locked التي تقول "إذا كان package.json غير راضٍ عن yarn.lock ، فهذا خطأ فادح". يحتوي Bundler على علامة مماثلة ( --frozen ) ، والتي تمت إضافتها عندما اعتمد Heroku Bundler ، لإعطاء الناس خطأ فادحًا إذا قاموا بإجراء تغييرات محلية على Gemfile ونسوا إيداع Gemfile.lock .

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

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

esphen قال:

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

أعتقد أن هذا غير مثير للجدل.

مع npm ، كان لدي العديد من حالات انضمام المطورين إلى مشروع ، فقط للعثور على مشروع لا يعمل على أجهزتهم. حدثت هذه الحالات بسبب التبعيات العابرة التي تصطدم بالإصدارات مع التغييرات المعطلة أو ببساطة لا تتبع semver. كنت آمل أن يحل الغزل هذه المشكلات ، ولكن إذا كانت الوجبات الجاهزة هي أن جميع المطورين في المشروع يجب أن يقوموا بتثبيت الغزل - pure-lockfile للتأكد بنسبة 100 ٪ من أن المشروع سوف يبني ، فهذا ليس هو الحال.

تشغيل yarn install --pure-lockfile سيعني أنه سيتم احترام ملف القفل حتى إذا تعارضت الإصدارات الموجودة داخل ملف القفل مع الإصدارات المحددة في package.json . يجب أن يظهر هذا في المقام الأول فقط إذا نسي المطور التحقق في yarn.lock بعد إجراء التغييرات على package.json .

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

إذا لم يتغير package.json ، في رأيي أنه خطأ إذا تم تحديث yarn.lock . يبدو أن هناك حالة واحدة على الأقل من الخطأ في التقرير الأصلي:

يتم تعديل lockfile اعتمادًا على البيئة (إصدار الغزل المثبت حاليًا).

أعتقد أن هذا خطأ ويجب تصحيحه.

في وقت لاحق من الموضوع ، قال thejameskyle :

تخيل وظيفة memoize حيث يكون الإدخال عبارة عن package.json والإخراج هو yarn.lock.

هذا هو بالضبط النموذج العقلي الصحيح ، من وجهة نظري ("يمكن أن يتغير yarn.lock إذا وفقط إذا تغير package.json ") ، وإذا تسرب التجريد يجب علينا إصلاحه.

adamchainz قال:

مزيد من المعلومات حول ما سبق: يحتوي بناؤنا على قهوة من جيثب كاعتماد فرعي. دفع coffeescript بعض الالتزامات وحصلنا على yarn.lock معدل في عملية البناء لدينا من تشغيل تثبيت الغزل فقط

و لاحقا:

ولكن لديه السلوك السيئ إذا تم تثبيت التبعية من جيثب ، كما ذكرت أعلاه

تكمن المشكلة هنا في أن الغزل لا يتعامل مع git sha كجزء من الإصدار المقفل من تبعيات git. كل من Cargo و Bundler لديهما مفهوم الإصدار "الدقيق" الذي يتم تسلسله إلى ملف lockfile ؛ بالنسبة لمصادر git ، فإن الإصدار "الدقيق" هو ​​SHA. بعد ذلك ، عندما تقوم بعمل نسخة جديدة باستخدام package.json و yarn.lock وتشغيل yarn ، فإن كل المعلومات المطلوبة للحصول على الكود الذي تحتاجه بالضبط موجودة.

يجب أن أعترف بأنني فاتني هذا التفاعل عند مراجعة كود git الأصلي ؛ هناك بعض تتبع SHA في الشفرة ، لكن yarn install لا يضمن أن الرسم البياني للتبعية المائية يحترمها.

TL ؛ DR

أتفق مع thejameskyle و @ kittens على أن yarn.lock يجب أن يظل متزامنًا مع package.json تلقائيًا ، لأنني أعتقد أنه يجب أن يكون المستخدمون قادرين على افتراض أن الإصدارات المحددة في package.json يتماشى مع ما يتم استخدامه عند تنفيذ تطبيقهم.

ومع ذلك ، يبدو أن هناك بعض الأخطاء التي تتسبب في حدوث اضطراب غير مناسب في yarn.lock حتى عندما لا يتغير package.json :

• التغييرات التي تم إجراؤها على إصدار الغزل عبر الأجهزة تعمل على تحديث ملف القفل
• يتم تحديث تبعيات git حتى إذا لم يتم تحديث package.json ، والذي يقوم بعد ذلك بتحديث ملف القفل

يجب أن نفكر أيضًا في شيء مثل علامة Cargo --locked ، والتي يمكنك استخدامها في CI لفشل سريع في الإنشاء إذا قام أحد المطورين بتحديث package.json ونسي التحقق في yarn.lock المحدث

تضمين التغريدة : قلب: أتفق معك ومع @ القطط على أنه يجب تحديث yarn.lock بعد تغيير package.json

wycats منشور شامل --locked (أو ما شابه). يجب أن نخلق قضية جديدة حول ذلك.

صنع # 1568 لتتبع مشكلة git SHA

wycats ، شكرًا على النظرة العامة الثاقبة

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

هذا هو بالضبط سيناريو فتح هذه المشكلة.
لدينا عدد قليل من الإصدارات النشطة من Yarn في الشركة وعلى نطاقنا لا أعتقد أننا سنكون قادرين على إجراء تحديثات ذرية في كل مكان.
قدم البناء على الغزل 0.13 و 0.14 و 0.15 اختلافات طفيفة في ملفات yarn.lock على الرغم من أن package.json كان متزامنًا.
تسبب هذا في بعض المشكلات ، على سبيل المثال تم إبطاء إصدارات Buck لأن التغييرات في شجرة المصدر تبطل ذاكرة التخزين المؤقت.
لقد تسبب هذا لي ولفريقين في العمل لساعات قليلة.

thejameskyle ، شكرا
لم أعتبر سيناريو package.json غير متزامن مع yarn.lock ، ليكون عادلاً. ولديك نقطة صحيحة.

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

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

لنكون أكثر دقة ، فإن الدلالات المتوقعة ، في رأيي ، هي:

• إذا لم يتغير package.json منذ آخر مرة تغير فيها yarn.lock ، فإن yarn.lock هو مصدر الحقيقة ويجب عدم تحديثه.
• إذا تغير package.json منذ آخر مرة ، تغير yarn.lock ، قم بتحديث yarn.lock حتى يرضي package.json وتحديث node_modules .
• إذا تم تشغيل yarn update ، فأعد حل جميع التبعيات واحصل على أحدث إصدار من كل شيء يفي بـ package.json .

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

هذه هي الدلالات التي نتبعها والتي أضفتها في # 364.

bestander لقد شاركت في العلاقات العامة (# 364) التي وضعت هذه الاستدلال في مكانها

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

@ kittens يبدو جيدًا ، سأقوم بتحديث المشكلة.
أو ربما يجب أن أفتح ملفًا جديدًا متعلقًا بتثبيت تغيير ملف القفل عندما لا يتغير package.json

هل يمكننا الانتقال إلى إصدار جديد؟ يمكن الاحتفاظ بهذه التعليقات هنا كأرشيف

يبدو هذا جيدًا ، thejameskyle ، سأقوم بإنشاء عدد جديد اليوم

تم إنشاء الإصدار الجديد المركّز https://github.com/yarnpkg/yarn/issues/1576

سيكون من المثير للاهتمام أن يكون لديك خيار لجعل yarn install يفشل إذا لم تكن الحزمة في package.json في yarn.lock ، أي. تفشل إذا لم يتم قفل أي حزمة

مضيفا الإيضاح الذي كان لا يزال غامضا بالنسبة لي بعد قراءة ما سبق:

TLDR. لن تؤدي التغييرات غير ذات الصلة في package.json إلى تحديث حزمة إلى أحدث إصدار متوافق مع semver package.json يتغير.

استنادًا إلى بعض الصياغة أعلاه ، يبدو أن yarn.lock تم تخزينه مؤقتًا على تجزئة package.json ، وبالتالي يبدو أنه سيتم كتابة yarn.lock إلى (تم التحديث / ذاكرة التخزين المؤقت غير صالحة ) على أي تغيير إلى package.json ، والذي سيكون مشكلة لأن التغيير غير ذي الصلة (على سبيل المثال ، التحديث إلى "description" أو تبعية أخرى) قد يتسبب في تحديث إصدار هذه التبعية yarn.lock إلى إصدار أحدث داخل نفس package.json semver الحالي.

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

على سبيل المثال،

• قل yarn add lodash@^4.17.1 تثبيت [email protected]
• في وقت لاحق ، يتوفر [email protected] .
• سيستمر الغزل في تثبيت [email protected]
• ما لم / حتى يتم تغيير إصدار اللوداش في package.json (أو يتم تشغيل إضافة / ترقية / إزالة الغزل على وجه التحديد ضد لوداش).

مسار التنقل # 1576

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

CrabDude شكرا لتقاسم التوضيح الخاص بك.

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

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

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

هل تقصد - في المثال أعلاه - أنه سيتم تحديث إصدارات القفل الخاصة بهم في yarn.lock؟

نعم فعلا. يبدو أن هذا تم تأكيده في نموذجي.

هل سيتم الآن تحديث جميع الحزم القديمة الأخرى في yarn.lock ، أم ستظل كما هي؟

يبدو أنه لن يتم تحديث أشجار التبعية غير lodash / إدخالات قفل الحزم ؛ فقط التبعيات الفرعية لـ lodash ستكون.

من وجهة نظري ، كل من هذه الأشياء مرغوب فيه ومتوقع.

مقدمة : أحب الغزل. لكنه يحبطني بلا نهاية.

في شركتي ، يقوم yarn install بتغيير ملف القفل باستمرار عبر أجهزة مختلفة (كل منها يعمل بالإصدار نفسه) ، على الرغم من عدم تغيير package.json . وعندما نفعل ذلك ، نقوم بالتحديث باستخدام yarn add . هذا أمر مزعج لأن CI تتحقق من أن حالة git نظيفة بعد الإنشاء للتأكد من أننا لم ننسى القيام بأشياء مثل إيداع ملف القفل ، وهو يتغير كثيرًا.

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

أسئلة

• هل يقال أنه على الرغم من تغيير ملف القفل ، فإن محتويات وحدات العقدة ستكون دائمًا مطابقة لما تم إنشاؤه؟ لا أعتقد أن هذا هو الحال ولكن إذا كان الأمر كذلك ، فأنا أفهم الالتباس في هذا الخيط - فهذا يعني أن الغزل يفعل الشيء الصحيح على الرغم من المظهر الذي لا يفعله.
• عندما يتغير package.json ، يتم إعادة إنشاء ملف القفل. ألا يمكن أن يغير ذلك بدون قصد الكثير من التبعيات اعتمادًا على حالة وحدات عقدة_عقد هذا المبرمج المعين؟ يجب أن يحدد الغزل دلتا ويحاول الحفاظ على الأقفال الموجودة بأفضل ما يمكن (إذا لم يكن كذلك بالفعل).
• لماذا يحدد yarn add الإصدارات في package.json مع ^ ؟ مرة أخرى ، فهمت أن وعد الغزل كان تجميد التبعيات.

الأخطاء ذات الصلة

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

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

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

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

هل أنت في أحدث إصدار من الغزل؟
اعتبارًا من 0.18-0.19 ، لا نرى تعديلات على ملفات yarn.lock بين الأجهزة.

أسئلة:

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

يمكن ترك Dev والاعتماديات الاختيارية في نفس ملف القفل.
لكن تلك التي تم تثبيت bing عليها ، باستثناء الحزم الخاصة بالنظام الأساسي ، يجب أن تحتوي node_modules على حزم متطابقة في أماكن متطابقة.

عندما يتغير package.json ، يُعاد إنشاء ملف القفل. ألا يمكن أن يغير ذلك بدون قصد الكثير من التبعيات اعتمادًا على حالة وحدات عقدة_عقد هذا المبرمج المعين؟ يجب أن يحدد الغزل دلتا ويحاول الحفاظ على الأقفال الموجودة بأفضل ما يمكن (إذا لم يكن كذلك بالفعل).

هذا طلب ميزة لطيفة ، أود أن أرى العلاقات العامة لذلك.

لماذا يضيف الغزل تحديد الإصدارات في package.json مع ^؟ مرة أخرى ، فهمت أن وعد الغزل كان تجميد التبعيات.

هذا يعكس سلوك npm.
يمكنك عمل yarn add [email protected] أو yarn add is-array --exact للإصدار الصحيح.
ربما في مرحلة ما يجب أن نجعل الإصدارات الدقيقة افتراضية ، يمكن أن تكون هذه مناقشة في RFC.

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

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

يميل ملف القفل إلى التجديد إذا حذفت node_modules وقمت بتثبيت نظيف (وهو حرفياً عكس ما تتوقعه - أتوقع أن يقوم بتثبيت ما هو موجود في ملف القفل بالضبط ولا يفعل شيئًا آخر على الإطلاق)

لم أر هذا منذ فترة.
افتح مشكلة ونسخة لي إذا كان من الممكن إعادة إنتاجها.

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

بعد مرور بعض الوقت ، ربما تم إطلاق إصدارات جديدة من التبعيات متعدية.
بسبب ذلك ، يمكن أن يتغير هيكل node_modules بشكل كبير بسبب منطق الرفع.
يعمل على النحو المصمم.
هناك أمر import قادم https://github.com/yarnpkg/yarn/pull/2580.
سيسمح لك ذلك بإنشاء ملف قفل من وحدات node_modules الحالية.

jspiro ، Yarn هو مشروع يحركه المجتمع الشاب ،

هل هناك أي فرصة للحصول على خيار على الأقل لتعيين السلوك الافتراضي المطلوب؟

نقوم حاليًا بإصلاح هذه المشكلة https://github.com/yarnpkg/yarn/issues/3490 ، أحيانًا قد يتسبب yarn install في تحسين ملف lockfile وهو سلوك غير متوقع وسنصلحه.
قد يكون هذا هو سبب مطالبتك بهذا التغيير ، وإلا فلن يتغير ملف yarn.lock إلا إذا أجريت تغييرات على package.json يدويًا.

يمكنك تعيين --pure-lockfile / - Frozen-lockfile على true في .yarnrc وسيتم إلحاقه بأمر التثبيت افتراضيًا:

--install.pure-lockfile true

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

هل يمكنك إرسال مشكلة مع خطوات repro؟
سنقوم بفرزها

لقد تعرضت للعض من هذا أيضًا عندما خرجت مزامنة package.json و yarn.lock بسبب قيام أحد المطورين بإضافة تبعية عن طريق الخطأ npm install --save بدلاً من yarn add .

لا أوافق على الرغم من أن pure-lockfile يجب أن يكون هو الخيار الافتراضي وأجادل أنه بدلاً من ذلك ، يجب أن يكون frozen-lockfile هو الخيار الافتراضي لـ yarn install .

نظرًا لأن frozen-lockfile ينتج عنه رسالة خطأ إذا لم تتم مزامنة yarn.lock و package.json . لذلك ، فإن frozen-lockfile مفيد جدًا في آلة البناء (مثل jenkins) لأنه سيحدد هذه الإنشاءات ، كما يجب أن يكون متوقعًا ، على أنها فشل.

بعد ذلك ، يعود الأمر للمطور ليقرر الإصدار المراد إضافته في package.json / yarn.lock.

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

يجب أن يكون الجوهر على الرغم من:

الأوامر مثل add و remove و upgrade يجب أن تغير yarn.lock .

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

لذلك فإن ملف القفل المجمد مفيد جدًا في بناء الآلة (مثل jenkins) لأن تلك الإنشاءات ستفشل.

أعتقد أنه يمكننا تمكين هذا تلقائيًا عندما نكتشف أننا في وضع CI؟

BYK لم أكن أدرك أن هذه المشكلة قد تم إغلاقها قبل الإضافة هنا. هل يجب أن أفتح واحدة جديدة أم يمكن إعادة فتحها؟

سأقول افتح واحدة جديدة ☺️

أتفق مع thejameskyle و @ kittens على أن yarn.lock يجب أن يظل متزامنًا مع package.json تلقائيًا

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