Yarn: تخلق ملفات القفل المتنافسة تجربة مستخدم سيئة

أضف config إلى package.json للإشارة

قد تكون حالة استخدام جيدة للحقل engine 🤔

جولة التعثر package-lock.json → yarn.lock → package-lock.json ضياع ، لكن هذا على الأرجح غير مهم. yarn.lock → package-lock.json → yarn.lock يجب ألا يكون ضائعًا ، AFAIK.

من وجهة نظر npm ، أفضل الخيار حيث إذا رأى yarn package-lock.json وليس yarn.lock يستورده ويزيل package-lock.json . وبالمثل ، إذا رأى npm yarn.lock ولا يوجد package-lock.json ، فيجب أن يفعل الشيء نفسه ، مع استيراد وإزالة `yarn.lock.

سيسمح ذلك لمستخدمي كلتا الأداتين بالتبديل بسلاسة ذهابًا وإيابًا دون ترك مشروع المستخدم في حالة مربكة (حيث يبدو أن الملفات من كليهما).

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

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

@ yarnpkg / الأساسية ، الأفكار؟

تعجبني فكرة @ iarna لجعل كلتا الأداتين تنتقل من ملف قفل واحد إلى
آخر عند التثبيت تلقائيًا.
من المنطقي حذف ملف القفل المستورد بعد الترحيل لتجنبه
كلا مديري الحزم المنافسة في مشروع واحد.

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

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

يوم الأربعاء 11 أبريل 2018 الساعة 9:49 مساءً كتب Maël Nison [email protected] :

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

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

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core ، الأفكار؟

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

Pingingimsnif حيث أعرب عن اهتمامه بتنفيذ حل "تحويل ملف القفل الآخر" قبل بضعة أسابيع. قد يكون لديه بعض كود العمل حتى الآن.

شكرا على ping!

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

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

لدي حاليًا بعض التعليمات البرمجية الأولية التي تقوم بهذا: https://github.com/imsnif/synp
إنه ليس 100٪ ويعتمد على مجلد node_modules حالي وحالي للمشروع المراد تحويله. أنا في مراحل الانتهاء من إعادة الكتابة (على الفرع 2.0.0 ) والتي ستحصل على حالة الحزمة من التسجيل (باستخدام pacote lib الرائع).

ما أريد القيام به بمجرد الانتهاء من ذلك هو البدء في الحديث عن كيف (وإذا؟) نود تنفيذ هذا بالضبط في كل من yarn و npm .

أحب أن أسمع أفكار الجميع حول هذا.

في نظري ، هذا مقبول تمامًا إذا كنا نتحدث عن سيناريو "التحويل لمرة واحدة" المذكور أعلاه

لا أعتقد أنه سيكون بهذا الشائع. قد أكون مخطئًا ، لكني أشعر أن حالة الاستخدام الأكثر شيوعًا ستكون المشاريع التي تستخدم Yarn ، ويقوم أحد المطورين بنسخ / لصق الأمر من README لإضافة تبعية ، باستخدام npm بدلاً من yarn في هذه العملية.

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

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

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

أرى أن هذه الميزة تُستخدم بشكل أساسي في بيئات CI ، حيث أعتقد أنها يمكن أن تتألق (كما ذكر OP).

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

على أقل تقدير ، أعتقد أنه يجب أن تكون كلتا الأداتين على دراية بملف قفل الأداة الأخرى؟

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

في رأيي ، فإن تحويل ملفات القفل أثناء التنقل ليس قابلاً للتطوير أيضًا. على سبيل المثال ، كنا نتحدث فقط عن ملف package-lock.json حتى الآن ، لكنني أعتقد أن pnpm لديه ملف قفل خاص به يسمى shrinkwrap.yaml . سيكون من اللطيف أن نجد طريقة للتعامل مع كل منهما وأي تنسيق آخر قد يأتي بحجر واحد.

أرى أن هذه الميزة تُستخدم بشكل أساسي في بيئات CI ، حيث أعتقد أنها يمكن أن تتألق (كما ذكر OP).

لاحظ أيضًا أنه إذا فهمت بشكل صحيح ، فإن npm تعمل حاليًا على مدير حزم خفيف جدًا خاص بـ CI ، والذي قد لا يعمل بشكل جيد مع الأشياء التي تتطلب منطق عمل ثقيل مثل محول lockfile.

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

عندما عملت سابقًا في بيئة npm / خيوط مختلطة ، سنفعل ذلك يدويًا باستخدام سجلات git. لقد كانت عملية شاقة وأنا متأكد من أننا كنا / لسنا وحدنا في ذلك.

بالنسبة لقابلية التوسع:
أود حساب هذا أيضًا.
عند إجراء التحويل ، يتم إنشاء شجرة حزمة منطقية ومادية وسيطة (إذا كان لملف القفل واحدة). عند التحويل إلى ملف القفل المطلوب ، يتم استخدام تلك الأشجار (أو يتم إنشاؤها باستخدام الإعدادات الافتراضية المعقولة في حالة التحويل من yarn وليس لدينا شجرة فعلية).
بهذه الطريقة ، يمكننا التحويل بسهولة بين أنواع ملفات القفل الأخرى (كل ما نحتاج إليه هو توفير تحويلات من / إلى شجرة منطقية / فعلية لكل نوع).

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

(بالنسبة لأداة ci الجديدة الخاصة بـ npm - أرى ما تقصده ، لكنني أعتقد أن هذا قبل المناقشة الحالية بقليل؟)

أو بشكل أكثر تحفظًا: فشل افتراضيًا في تثبيت جديد والسماح شفهيًا بالتحويل من خلال أمر استيراد

نعم ، سأكون تمامًا لإضافة منطق التحويل هذا إلى الأمر yarn import ، يبدو أنه ميزة مفيدة يمكن استخراجها في حزمة منفصلة إذا / عندما نصل إلى تنفيذ ملحقات Yarn :) تعليقاتي هي التركيز على السلوك الافتراضي الذي يجب أن نتبناه.

اعتبارًا من npm@6 ، يجب أن تكون قادرًا على تحويل package-lock.json -> yarn.lock بدون خسارة ، دون الحاجة إلى تشغيل التثبيت أولاً. يجب أن يحتوي على جميع البيانات التي تحتاجها ، والمعرفات ، وما إلى ذلك (يحتوي pkglock npm @ 6 على نطاقات إصدارات في الحقل requires ، والذي يتطابق مع ما يستخدمه yarn.lock ؟)

أوه ، وتحتاج أيضًا إلى https://github.com/yarnpkg/yarn/pull/5042 ليتم شحنها قبل أن يكون هذا صحيحًا أيضًا ، نظرًا لأن npm لا تحتوي على sha1 في pkglock في كثير حالات.

arcanis - رائع! وكذلك العلاقات العامة مع:

1. تحذير عند تثبيت ملف package-lock.json والعثور عليه
2. تحذير عند إضافة ملف package-lock.json والعثور عليه
3. إضافة القدرة على التحويل من package-lock.json عبر الأمر import (وحذف الملف بعد ذلك)
   كن مقبولا؟ (فقط حتى يكون لدينا شيء يمكننا استخدامه لبدء المحادثة حول التفاصيل)

zkat - هذا رائع حول npm@6 ! إذا كان الأمر متروكًا لي ، فسأختار استخدام ذلك والعودة إلى ملفات البيان من أجل دعم جميع إصدارات lockfile. هل يمكنني أن أسأل عما إذا كنت منفتحًا على تنفيذ سلوك مشابه (أو ربما مختلف نوعًا ما) مقابل npm ؟

لاحظ أيضًا أنه إذا فهمت بشكل صحيح ، فإن npm تعمل حاليًا على مدير حزم خفيف جدًا خاص بـ CI ، والذي قد لا يعمل بشكل جيد مع الأشياء التي تتطلب منطق عمل ثقيل مثل محول lockfile.

إذا كنت تقصد بعبارة "العمل حاليًا" "تم الشحن" ، فحينئذٍ نعم. =)

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

تحذير عند تثبيت ملف package-lock.json والعثور عليه

أنا قلق من أن مجرد وجود تحذيرات عند وجود نوع غير مدعوم من ملف القفل لن يساعد في حل المشكلات التي أثارتها jmorrell التي يواجهها Heroku؟

أنا قلق من أن مجرد وجود تحذيرات عند وجود نوع غير مدعوم من ملف القفل لن يساعد في حل المشكلات التي أثارتها jmorrell التي يواجهها Heroku؟

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

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

لقد تواصلت مع بعض الأشخاص الذين لديهم خبرة أكبر مع المطورين المبتدئين الذين نأمل أن يتناغموا مع ما تبدو عليه هذه التجربة لشخص ما بدأ للتو.

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

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

أنا قلق من أن مجرد وجود تحذيرات عند وجود نوع غير مدعوم من ملف القفل لن يساعد في حل المشكلات التي أثارتها jmorrell التي يواجهها Heroku؟

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

السؤال صادقة لأولئك اقتراح تحذير: هل هناك الحالة التي يكون فيها تشغيل yarn install أو yarn add في حين أن package-lock.json غير أن الحاضر لا يمكن أن يكون خطأ؟ نفس الشيء مقابل npm install و yarn.lock

يتبادر إلى الذهن الترحيل من npm إلى Yarn ، أو من Yarn إلى npm. أفضل تجنب إضافة الاحتكاك عندما يريد المرء تجربة مديري الحزم الآخرين.

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

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

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

هل هناك حقل engine أم أنك تشير إلى engines ؟ لا يمكنني العثور على أي مستندات تشير إلى engine . أعتذر إذا فاتني شيء.

ندعم تحديد الإصدارات في الحقل engines : https://devcenter.heroku.com/articles/nodejs-support#specifying -an-npm-version

مثال:

  "engines": {
    "npm": "5.6.x"
  }

هناك بعض المخاوف التي لدي بشأن استخدام هذا لتحديد مدير الحزم الذي يجب استخدامه:

• الطريقة التي تبدو بها الأشياء اليوم: عدد غير ضئيل من المستخدمين لديهم تعريف لكل من npm و yarn ، أو إصدار npm ، ولكن بعد ذلك لديهم yarn.lock . يمكن للإصدارات المستقبلية من npm و yarn فرض ذلك ، لكن المستخدمين الذين لا يقومون بالترقية بشكل متكرر سيستمرون في استخدام الإصدارات الحالية لفترة طويلة.

• لا يلمس معظم المستخدمين هذا التكوين أبدًا. قاموا بتشكيل نموذج معياري قديم يحدد Node 0.10 على الرغم من أنهم يستخدمون كل ما قاموا بتنزيله من nodejs.org على أجهزتهم. هذا يتسبب في عدد غير تافه من القضايا على Heroku.

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

مثال: "لقد استنسخت مثال مشروع hello-world ، ونزلت Node من https://nodejs.org ، ولم يعمل"

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

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

يفرض AFAIK Yarn هذا الحقل بشكل صارم إلا إذا قمت بتمرير علامة لتعطيل ذلك.

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

هذا أمر خطير للغاية ، خاصة عند استخدام الغزل لأنه يضمن الاتساق فقط عبر نفس الإصدارات الرئيسية من الغزل.

لا يعني هذا أن هذا مثالي ، لكن ما أفهمه هو أن غالبية مستخدمي npm / الغزل مبتدئين ، وهذا يضيف عقبة جديدة أمام البدء.

ماذا عن الغزل (وأيضًا npm ، إذا أحبوا الفكرة) إضافة إدخال "yarn": "^<current_version>" في حقل engines للمساعدة في تقديم بعض الأمان دون الكثير من الاحتكاك؟ يمكننا إضافة هذا تلقائيًا عند تشغيل yarn init أو yarn import أو عند إنشاء ملف قفل من البداية.

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

أعتقد أن الهدف النهائي يجب أن يكون مشاركة تنسيق ملف قفل واحد بين Yarn و npm.

thatlittlegit ستسعد بمعرفة https://github.com/yarnpkg/yarn/pull/5745 بعد ذلك. (ستقوم npm بالشيء نفسه بالعكس ، لذا سننتهي في مكان لا يهم فيه نوع ملف القفل الذي تعمل منه أو الأداة التي تختارها)

تم التعديل للإضافة

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

BYK قد يكون من المفيد هنا بعض السجل حول سلوك حقل المحرك:

في npm @ 1 و npm @ 2 ، كان لدينا package.json يسمى engineStrict بالإضافة إلى الحقول engine . إذا كان engineStrict صحيحًا ، فعندئذٍ تم استخدام حقل المحرك كقيود حل_ وقبل أن نطبق نطاق semver على قائمة الإصدارات ، سيتم تصفية الإصدارات ذات المحركات غير المتوافقة. سيتيح لك ذلك القيام بأشياء مثل npm install foo والحصول على [email protected] حتى إذا تم نشر [email protected] إذا لم يكن [email protected] مدعومًا على النظام الأساسي الخاص بك. هذا _ يبدو مطلوبًا ، ولكنه عمليًا كان مربكًا للغاية ، لا سيما لأن المستندات الموجودة على موقع الويب كانت فقط للإصدار الأحدث.

إذا كان engineStrict خاطئًا ، فسيتم إجراء الحل بغض النظر عن حقول المحرك وتم إصدار التحذيرات إذا كانت النتيجة غير متوافقة.

كان هناك أيضًا خيار تهيئة engine-strict ، والذي قام بنفس الشيء مثل خاصية package.json ، لكنه طبقه على ALL الحزم.

بدءًا من npm @ 3 ، أسقطنا دعم الخاصية engineStrict package.json وغيرنا سلوك خيار التهيئة engine-strict . يعمل خيار التكوين الآن على تحويل التحذيرات التي تحصل معها إلى أخطاء ، ولكنها لا تؤثر على الدقة.

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

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

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

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

ماذا يعتقد الجميع؟ jmorrell ، BYK ، arcanis ،iarna؟

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

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

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

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

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

لا يعتبر الغزل بديلاً مباشرًا من حيث واجهة برمجة التطبيقات المكشوفة. إن yarn add <pkg> مقابل npm install <pkg> هو مثال واضح على شيء نقوم فيه بالأشياء بشكل مختلف. نميل إلى امتلاك نفس مجموعة الميزات ، ولكن في النهاية هناك أداتان مختلفتان وأحيانًا يكون لدينا حلول مختلفة لنفس المشكلة.

يعد yarn.lock مقابل package-lock.json أحد تلك الاختلافات وأعتقد أنه لا Yarn ولا npm مهتمان باستخدام واحد ، حيث أنهما يحتويان على معلومات مختلفة.

على جانب الغزل ، أقترح البدء بتحذير (كما هو مذكور أعلاه)

سأكون بخير مع هذا. شيء مثل:

WARN Your project seem to contain lock files (package-lock.json, shrinkwrap.json) generated
WARN by other tools than Yarn. It is advised not to mix package managers, in order to avoid
WARN resolution inconsistencies caused by desynchronized lock files.

هل يريد شخص ما فتح علاقات عامة؟

سأكون سعيدًا بفتح علاقات عامة تضيف تحذيرًا :)

هل الحل النهائي المطلوب هنا خطأ مفيد عند وجود package-lock.json + yarn import ؟ كنت أفهم أن iarna كان يدعو إلى أن كل أداة يجب أن تزيل / تحوّل ملف القفل المعاكس إذا كان موجودًا تلقائيًا.

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

jmorrell - كنت أفهم أننا اتفقنا على أن التحويل التلقائي فكرة سيئة هنا.

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

آمل أن يتفق الأشخاص npm على هذا؟

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

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

arcanis npm add <pkg> صالح تمامًا ويفعل ما يفعله الغزل 👼

بالنسبة إلى pkglock مقابل yarnlock ، كان الهدف الأصلي من package-lock.json هو إنشاء تنسيق يتضمن جميع البيانات التي يحتاجها مدير الحزم. في الواقع ، يمكن تحويل pkglock اعتبارًا من npm@6 بشفافية إلى yarn.lock بدون تنفيذ مُثبِّت ، لأنه يصف شجرة كاملة مع جميع البيانات الوصفية ذات الصلة. لقد فعلنا ذلك عن قصد (مثل الحقل requires ) ، وطلبنا تعليقات من كل من فريقي الغزل و pnpm للتأكد من أن كل ما فعلناه كان كافياً لكليهما لاستخدامه إما كملف قفل قابل للاستيراد أو كخيار بديل. yarn.lock هو ، للأسف ، مجموعة فرعية ضائعة ، لذا فإن العكس ليس صحيحًا ، لكننا سنضيف أشياء لاستيرادها على أي حال. حتى أن npm ستطيع أشكال الأشجار المحسوبة بواسطة الغزل (على عكس الغزل ، الذي لن يفعل ذلك).

في الواقع ، يمكن تحويل pkglock اعتبارًا من npm @ 6 بشفافية إلى yarn.lock دون تنفيذ مُثبِّت ، لأنه يصف شجرة كاملة مع جميع البيانات الوصفية ذات الصلة.

لا أعتقد أن ذلك ممكن (لكن ربما أكون مخطئًا ، فلا تتردد في الإشارة إلى أي سوء فهم). لا يدعم ملف قفل الغزل من خلال تصميم نطاقات متعددة يتم حلها في إصدار واحد. إذا كان لديك حزم متعددة تعتمد كل منها على lodash@^1.0.0 ، فستستخدم جميعها نفس الإصدار بالضبط. إنه ليس مجرد تحسين ، ولكن أيضًا كيف نقوم بتشفير الأشياء في ملف القفل الخاص بنا.

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

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

لأكون صريحًا ، لست متأكدًا تمامًا مما إذا كنا نقول نفس الشيء أو شيئًا مختلفًا تمامًا ، أردت فقط توضيح الموقف قليلاً 🙂

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

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

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

هل الحل النهائي المطلوب هنا خطأ مفيد عند وجود package-lock.json + استيراد الغزل؟

نعم ، إلى جانب وضع "الترقية إلى خطأ على CI" * أعتقد أنها خطوة أولى معقولة!

(* هذا غير موجود بعد ، سأذكره في # 5773 Yarn 2.0 WG)

arcanis - حول ملفات القفل: أعتقد أن ما يشير إليه zkat (لكن من فضلك @ zkat صححني إذا كنت مخطئًا أو أسيء فهمي) هو أن package-lock.json يحفظ الشجرة المادية وكذلك المنطقية ، بينما yarn.lock يحفظ package-lock.json => yarn.lock => package-lock.json إلى فقد بيانات الشجرة الفعلية. IMO هذا جيد في معظم الحالات ، ولكن هناك استثناءات: على سبيل المثال. التبعيات المجمعة.

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

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

أيضًا - في الحالة التي وصفتها أعلاه ، قد يتم وضع ملف القفل "الأجنبي" بشكل مفهوم في .gitignore وبالتالي لن تتاح الفرصة لـ CI للتعرف عليه. بصفتي مطورًا شارد الذهن ، قد أفكر "حسنًا ، هذا يعطيني بعض التحذير الغامض بشأن بيئتي المحلية ، ولكنه يتجاوز CI - لذلك ربما تكون مجرد مشكلة محلية من جانبي - حسنًا"

قد يتم ابتلاع تحذير (كما ذكر سابقًا هنا) في عدد غير قليل من التحذيرات الأخرى التي يميل المطورون إلى تجاهلها إذا كانت حالة الخروج هي 0.

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

بالإضافة إلى ذلك ، أعتقد أنك تتجاهل نوعًا ما قصة المستخدم "أنا أستخدم مدير حزم وأريد تجربة مدير آخر" ، وهو أمر أعتقد أنه مهم جدًا لكل المعنيين ، سواء المشرفين على إدارة الحزم أو المستخدمين على حد سواء. لن يكون رائعًا إذا لم يتمكن الأشخاص من تجربة npm 6 بسهولة من مشروع Yarn الخاص بهم (أو على العكس من ذلك ، تجربة Yarn من مشروع npm الخاص بهم).

رأيي الشخصي هو أن مديري الحزم يمكن أن يستفيدوا من مزامنة بناءهم لشجرة مادية.

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

• سيتجاهل ملفات التكوين
• سيؤدي إلى كسر الشجرة الفعلية في المرة التالية التي تتم فيها إضافة / إزالة الحزمة
• لن تعمل أي ميزة فريدة لمدير الحزم (مساحات العمل ، تجاوز الدقة ، الرابط: ، ...)

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

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

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

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

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

أعتقد أن المحادثة هنا خرجت عن مسارها قليلاً لذا أريد أن أرتبها ببعض التوضيحات والملخص:

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

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

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

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

أفكار؟

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

BYK - يبدو رائعًا. مع إضافة واحدة: كما أقنعنيarcanis هنا وفي الخلاف ، قد يكون من الجيد أيضًا إضافة تحذير في الوضع non-ci عندما لا يتم تعيين علامة التكوين. حتى يتسنى للمطورين معرفة أن بناء CI الخاص بهم قد يفشل قبل أن يدفعوا (وكذلك للحماية من package-lock.json في .gitignore ).

arcanis كما ذكر imsnif : يتضمن pkglock _both_ التخطيط المنطقي والمادي للشجرة. باتباع الإصدار المنطقي للشجرة (والذي يتضمن النطاقات التي استخرجناها من) ، يمكنك إنشاء yarn.lock في الذاكرة بدون تثبيت أو تشغيل منطق المثبت على الإطلاق. عمليات البحث عن الشجرة فقط :)

من ملاحظات إصدار NPM 5:

ميزة ملف قفل قياسية جديدة مخصصة للتوافق مع مدير الحزم (package-lock.json)

يبدو أن فريق NPM يعلن عن package-lock.json كحل عالمي ؛ هل من الممكن (فنيا) الالتحاق بهذه القوة؟

أحد الحلول التي أود اقتراحها هو "استخدام package-lock.json عندما يكون موجودًا بالفعل". هذه هي الطريقة التي "انتقلت بها" NPM من shrinkwrap إلى ملف json lock.

يبدو أن فريق NPM يعلن عن package-lock.json كحل عالمي ؛ هل من الممكن (فنيا) الالتحاق بهذه القوة؟

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

أعتقد أنك تتجاهل نوعًا ما قصة المستخدم "أنا أستخدم مدير الحزم وأريد تجربة مدير آخر" ، وأعتقد أنه مهم جدًا لجميع المعنيين

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

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

أرغب في استخدام الغزل ، لكن معظم المشاريع التي أعمل عليها لا تحتوي إلا على ملفات package-lock.json . لا يمكنني إضافة ملفات yarn.lock . yarn import بطيء و / أو معطل. حاليا بلدي
_only_ الخيار هو التخلص من الغزل والتبديل إلى npm.

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

مرحبًا Spongman - يجب ألا يتم كسر yarn import . من المفترض أن يتمكن الآن من استيراد package-lock.json نيابة عنك. إذا كنت تواجه مشكلات ، فيرجى إخبارنا بذلك!

فعلت # 6103

مرحبًا Spongman - لقد علقت على المشكلة ، هذه الحالة المحددة كانت بسبب تلف package-lock.json . يسعدني أن أعرف أي مشاكل أخرى.

يمكن أن تستخدم npm هذا الملف package-lock.json ما يرام. يحتاج الغزل إلى أن يكون أكثر مرونة.

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

كنت أشاهد وشارك في https://github.com/yarnpkg/yarn/issues/3614 (حاليًا 254: +1: s). تم الآن إغلاق هذه المسألة وانتقلت المناقشة هنا.

تجاهل التحديات العملية ، في رأيي إلى حد بعيد ، سيتم توفير أفضل تجربة مستخدم من خلال خيار غير مذكور في الملخص في الأعلى ، ولكن ذكره

أعتقد أن الهدف النهائي يجب أن يكون مشاركة تنسيق ملف قفل واحد بين Yarn و npm.

وهو أيضًا مدعوم بنقطةBrainBacon :

يبدو غريباً بالنسبة لي أن أي نوع من المشاريع يجب أن يحدد أداة إدارة الحزم التي يجب استخدامها.

مرة أخرى ، بتجاهل التحديات العملية لمدة دقيقة ، تم تقديم الحجة النظرية المضادة لهذا من قبل iarna في هذا الموضوع (و jhabidas في الموضوع الآخر ):

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

أنا شخصياً لا أعتقد أن هذه الحجة يجب أن تنطبق في هذه الحالة ، كما ذكرت في تعليق على الموضوع الآخر (مع 95: +1: s ، 2: -1: s):

نعم أوافق ، تريد Yarn الحفاظ على مساحتها المستقلة قدر الإمكان ، لذلك فهي تتمتع بالمرونة لتوفير تجربة أفضل. ولهذا السبب ، على سبيل المثال ، لا تتوافق واجهة سطر الأوامر من Yarn مع معايير NPM.

ومع ذلك ، أعتقد أن ملفات القفل موجودة خارج المساحة حيث يمكن لـ Yarn الحفاظ على استقلاليتها بشكل معقول. تم الالتزام بالمستودع package-lock.json و composer.lock إلى جانب package.json و composer.json . هذه ليست ملفات خاصة بالأداة ، بل هي ملفات خاصة بالمشروع تحدد إصدارات التبعية الدقيقة التي يضمن المشروع العمل معها.

...

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

بعد قراءة معظم هذا الموضوع ، ما زلت أتفق مع تقييمي الأولي - إذا استمر Yarn في استهلاك نفس ملف التبعية package.json من المستودع ، فمن الأفضل أن يرسل الملف package-lock.json في المستودع ، لذلك يمكن أن يظل المستودع حياديًا للأدوات. إذا قرأت Yarn تبعياتها من yarn.json بدلاً من package.json فلن أستمر في توضيح هذه النقطة.

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

أعتقد أن تنسيق ملف القفل الفردي ليس نتيجة محتملة نظرًا لوجود مقايضات مختلفة بين تنسيقات ملفات القفل وعدم وجود توافق في الآراء بشأن أيهما أفضل

(على الرغم من أنني لا أوافق على أن "وجود كلتا الأداتين قادرتين على فهم ملفات القفل الخاصة ببعضهما البعض بشكل متبادل كافٍ").

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

• سيصدر NPM / Yarn تحذيرات إذا اكتشفوا ملف قفل الآخر (وربما خيار تكوين لجعل هذا خطأ)
• توفر كلتا الأداتين آليات لتحويل ملف قفل إلى ملف آخر

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

كما أنني لا أتفق مع وجهة نظر imsnif :

لا أعتقد أن هناك سببًا وجيهًا لأن يكون لحزمة واحدة كل من package-lock.json وملف yarn.lock.

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

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

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

لاحظ أن الافتراض الخفي في الحل الوسط المذكور هو أن اختيار الأداة يكون واحدًا لكل مشروع وليس لكل آلة مطور أو بيئة إنتاج.

لاحظ أن الافتراض الخفي في الحل الوسط المذكور هو أن اختيار الأداة يكون واحدًا لكل مشروع وليس لكل آلة مطور أو بيئة إنتاج.

نعم ، أعتقد أن هذا هو أكثر ما يقلقني - على الرغم من أنني أعتقد في السيناريو الذي أشرت إليه أعلاه أنه لا يزال من الممكن الحصول على دعم المشروع لكل من Yarn و NPM.

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

إذا كانت npm lockfiles تحتوي بالفعل على مجموعة شاملة من علاقات التبعية التي تدعمها ملفات قفل Yarn ، فلماذا لا تدعم كليهما في Yarn؟ يمكن أن يتحول الغزل إلى package.json ويمكن إضافة أي حقول إضافية قد تكون مطلوبة بواسطة Yarn في المستقبل (على غرار الطريقة التي يدير بها بعض محرري SVG مثل Inkscape البيانات الوصفية للمحرر). بعد ذلك ، يمكن أن يكون لـ Yarn نفس تنسيق التبعية مثل npm ويكون متوافقًا مع yarn.lock ، مما يؤدي إلى تحويل ملفات قفل npm إلى أي بنية يريدها الغزل في الذاكرة.

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

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

أنا لا أقول أنها فكرة سيئة ، أنا فقط أقول أنني لا أشعر أنها فكرة عملية.

أنا لا أقول أنها فكرة سيئة ، أنا فقط أقول أنني لا أشعر أنها فكرة عملية.

أوافق على أنه يبدو طلبًا كبيرًا. لكن ما أقوله هو أن هذا يبدو وكأنه قضية محورية للمشروع.

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

في رأيي ، هناك ثلاث طرق للمضي قدمًا:

1. استمر في أن تكون بديلًا مؤقتًا لـ NPM من خلال إيجاد طريقة لمواءمة Yarn مع NPM على جميع واجهات مستوى المشروع (توحيد ملف القفل)
2. تعمد الاختلاف عن NPM باستخدام واجهات مختلفة على مستوى المشروع (على سبيل المثال yarn.json و yarn.lock )
3. ضاعف في توفير نصف واجهة NPMs وواجهة نصف مختلفة. هذا هو في الواقع نفس النقطة 2. ، ولكن أثناء النظر إلى معظم الناس مثل النقطة 1.

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

لا يزال من الممكن أن تكون متوافقة. يمكن أن يحتوي الغزل على محوّل ملف lockfile مدمج في npm ، لذلك عندما يرى package-lock.json ، سيحتفظ به هناك ويحوله إلى تنسيق yarn.lock في الذاكرة. على حد علمي ، لا يمكن لـ npm القيام بذلك لأن ملف قفل Yarn يحتوي على معلومات أقل من npm ، لذلك في رأيي سيكون من الأفضل لـ Yarn أن يتوحد مع npm.

nottrobin أعتقد أنك في الغالب على صواب في تحليلك ، ولكن:

الآن ، كما أشرت ، يتطلب الأمر من المشاريع أن تختار صراحة بين Yarn و NPM. هذا تغيير كبير ، ولا ينبغي أن يتم بالصدفة.

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

nottrobin - أتفق معVinnl. كما ذكرت أعلاه ، على الرغم من أنني لا أريد أن أكون في وضع يسمح لي بإخبار أي شخص كيف ينبغي أن يعمل ، أعتقد أن استخدام كل من الغزل و npm لتثبيت التبعيات في نفس المشروع هو مضاد.

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

ولكن هذا غير مجدي عمليًا إذا أضاف المطورون الآخرون / أزالوا التبعيات دون احترام ملف القفل هذا.

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

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

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

يبدو أنك تقول إن الغزل لم يعد مقصودًا أن يكون بديلًا سريعًا لـ npm؟ هل من المفترض أن يتم استخدامه فقط في مشاريع الغزل فقط؟

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

يبدو أنك تقول إن الغزل لم يعد مقصودًا أن يكون بديلًا سريعًا لـ npm؟

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

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

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

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

لم يكن كذلك

مخطئ ... عليك التحدث مع التسويق الخاص بك ، إذن. https://yarnpkg.com/lang/en/docs/

تتداخل الخيوط مباشرة مع العديد من ميزات npm ، بما في ذلك تنسيق البيانات الوصفية للحزمة ، مما يسمح بالترحيل غير المؤلم.

ليس لدينا أشخاص تسويق ، لكننا نقبل علاقات عامة جيدة 🙃

في هذه الحالة بالذات ، لا يبدو الأمر خاطئًا للغاية. نحن نتفاعل مع العديد من الميزات ، ولكن ليس مع جميع الميزات ، والترحيل غير مؤلم في معظم الحالات (في أسوأ الأحوال ، يكون على بُعد yarn import ).

الهجرة غير مؤلمة

أنا لست مهتمًا حقًا بالهجرة. أنا أبحث عن ما وعد به هنا (هؤلاء الأشخاص _definitely_ لديهم أشخاص تسويق): https://code.fb.com/web/yarn-a-new-package-manager-for-javascript/

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

اليوم ليس هذا الغزل.

AFAICT هناك 4 فئات من المستخدمين هنا:

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

لا أريد حقًا أن أكون في الفئة الأخيرة ، لكن يبدو أن هذا هو المكان الذي يتم دفعه فيه.

@ سبونجمان ما الذي يمنعك من آخر واحد؟ ربما يمكننا إصلاحه ؛)

@ Spongman أنا لست

(أعتقد أنه ربما لا يمكنك تعديل منشور المدونة ، ولكن ربما يكون موقع الويب هو الأهم هنا.)

أستطيع أن أرى من ردودimsnif و arcanis أن الموقف الرسمي هنا يبدو أن Yarn "لم يقصد أبدًا" الاستمرار في العمل بسلاسة جنبًا إلى جنب مع NPM.

لكنني أتفق تمامًا مع Spongman على أن هذا هو الانطباع الذي أعطته Yarn ، ولا أعتقد حقًا أن هذا كان حادثًا في ذلك الوقت. كان هذا هو عبقريته - كان بإمكانك تحسين السرعة والأمان وما إلى ذلك مع الاستمرار في دعم معايير NPM الرسمية تمامًا.

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

لكنني أعتقد أنك تقلل بشكل كبير من تقدير عدد الأشخاص الذين استخدموا الغزل على وجه التحديد لأنهم اعتقدوا أنها تحافظ على التوافق مع NPM (على مستوى المشروع) ، ولم تكن لتقوم بالتبديل بخلاف ذلك. أعتقد أن 254: +1: s و 10: heart: s على https://github.com/yarnpkg/yarn/issues/3614 و 57 تصويتًا مؤيّدًا على " هل يجب أن ألتزم yarn.lock و package-lock.json الملفات؟ "اجعل هذا واضحًا تمامًا.

إذا تخلى Yarn عن أي مسؤولية على هذه الجبهة ، أعتقد أنه لن يخسر فقط Spongman وفريقي ، ولكن أيضًا العديد من الآخرين.

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

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

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

Yarn هو مدير حزم جديد يستبدل سير العمل الحالي لعميل npm أو غيره من مديري الحزم بينما يظل متوافقًا مع سجل npm.

ما الذي يمنعك من آخر واحد؟ ربما يمكننا إصلاحه ؛)

zkat هذا مفيد ، شكرا لك.

nottrobin - لا يمكنني التحدث عن نوايا الغزل الأصلية لأنني لم أكن موجودًا في ذلك الوقت. ومع ذلك ، كنت أعمل في بيئة مختلطة من الغزل / npm مع عشرات المستودعات.

أستطيع أن أقول أنه كان واضحًا تمامًا لجميع المطورين المشاركين في ذلك الوقت أن اختيار الغزل / npm كان اختيارًا لكل ريبو ، تمامًا مثل اختيار express / hapi ، mobx / redux ، إلخ. أصبح هذا أكثر وضوحًا عند npm @ 5 خرج بتنسيق lockfile الخاص به وقرر بعض المطورين البدء في استخدامه مع مستودعات جديدة.

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

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

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

بصراحة ، لا أفهم حقًا المشكلة التي تواجهك مع استخدام الغزل فقط ، أو npm فقط.

نعم ، لقد أوضحتمarcanis و imsnif أنك لا تفهم. النقطة الوحيدة التي أوضحها هي أن الكثير من الأشخاص (انظر إلى: +1: s) قاموا بنفس التفسير "الخاطئ" ويريدون أن يعمل Yarn جنبًا إلى جنب مع NPM ، بغض النظر عما إذا كنت تفهم ذلك أم لا. إذا لم تكن الغزل هي الأداة بالنسبة لنا ، فليكن.

(مجرد نقطة أخيرة -imsnif من السخف تمامًا مقارنة أداة لتثبيت تبعيات Node بخيار مشروع مثل express vs hapi و mobx vs redux. هذه هي الخصائص الأساسية لتطبيقك. إذا لم تتمكن من رؤية الفرق الواضح ، لا عجب أنك لا تفهم وجهة نظري.)

على أي حال ، لقد انتهيت الآن. أعتقد أنني أوضحت وجهة نظري بقدر ما أستطيع.

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

^ هذا

أخشى أن هذا مفهوم خاطئ أيضًا. خلال العام الماضي ، انتقلت Yarn من 20٪ من إجمالي الطلبات إلى سجل npm إلى 40٪ في أبريل . في المرة الأخيرة التي سمعت فيها الإحصائيات (مباشرة من الأشخاص npm ، منذ تعطل إحصائياتنا مؤخرًا عندما انتقل سجل npm إلى Cloudflare) ، كان حوالي 48٪ من الطلبات. في العالم الحقيقي الفعلي ، يتعايش الغزل و npm ، سهل وبسيط.

سأكون ممتنًا الآن إذا كان بإمكاننا العودة إلى الموضوع المطروح ، وهو: من يرغب في كتابة علاقات عامة لكتابة تحذير عندما نكتشف ملف package-lock.json في وقت التثبيت؟ شكر.

Psst ، arcanis - https://github.com/yarnpkg/yarn/pull/5920

رائع: heart_eyes:

بين هذا وبين عملك على yarn import ، هل يمكننا إغلاق هذه المشكلة بعد ذلك؟

اعتقدت أننا سننتظر jmorrell لإعطائنا بعض الإحصائيات عن كيفية تأثير ذلك على المشكلة في Heroku حتى نتمكن من تحديد ما إذا كان هذا كافيًا أو نود تغيير شيء ما (تحذير / خطأ ، وما إلى ذلك) wdyt؟

تحرير: afaik لم يتم إصدار التحذير بعد ، لذلك لا يزال لدينا بعض الوقت للانتظار.

أخشى أن هذا مفهوم خاطئ أيضًا.

كيف ذلك؟ لا يخبرك حجم حركة المرور في npm بأي شيء عما إذا كان المشروع مفتوح المصدر أم لا.

سيكون التقييم الأكثر دقة هو حساب مشروعات جيثب التي تحتوي على 0،1 أو 2 من (yarn.lock، package-lock.json). شخصيًا لقد رأيت _ مطلقًا _ مشروعًا مفتوح المصدر (من أي حجم ملموس) على جيثب يحتوي على ملف yarn.lock و _no_ package-lock.json (باستثناء ما هو واضح).

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

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

لم أقرأ المداس بالكامل ، ولكن يجب على الأقل إخطار مستخدم IHMO بوجود غموض:

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

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

وكما هو مقترح أعلاه ، طريقة "لتفضيل" مدير الحزم (في package.json).

أستطيع أن أقول أنه كان واضحًا تمامًا لجميع المطورين المشاركين في ذلك الوقت أن اختيار الغزل / npm كان خيارًا لكل ريبو ، تمامًا مثل اختيار express / hapi ، mobx / redux ، إلخ.

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

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

"package-manager": "yarn"

أعتقد أن هذا هو الحل الأفضل ، إذا تم تنفيذه في جميع مديري الحزم.

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

أضف حقلاً في package.json للإشارة إلى مدير الحزم الذي يجب أن يستخدمه المشروع
"package-manager": "yarn"

أعتقد أن هذا هو الحل الأفضل ، إذا تم تنفيذه في جميع مديري الحزم.

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

أود أن أوصي ببعض حقول "مدير الحزم" الجديدة ، وبدلاً من ذلك أوصي بمقطع engines الذي يحتوي بالفعل على حالة سابقة.

يذكر كل من مستندات الغزل و npm (بشكل عابر) استخدام engines.npm و engines.yarn لتحديد إصدارات كل من المتوقع استخدامها. سوف يخطئ الغزل إذا كان إصدار الغزل لا يرضي engines.yarn .

https://yarnpkg.com/en/docs/package-json#engines -
https://docs.npmjs.com/files/package.json#engines

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

أود أن أرى تقاربًا بين مديري الحزم وليس تباعدًا.

متفق عليه. اما التقارب او الرفض.

لكن الوسط الحالي الخاطئ الغامض ضار.

ما زلت أعتقد أن مجرد إلقاء خطأ في وجود ملف قفل الآخرين سيتطلب أقل احتكاك للمشاريع الحالية.

إذا كنت تريد أن تفكر npm في ذلك ، فأنا أشجعك على فتح مناقشة في المكان المناسب

شكرا لك ، لقد قمت بالتسجيل للتو. هناك موضوع حديث في هذا الاتجاه: https://npm.community/t/npm-install-should-warn-about-the-presence-of-yarn-lock-files/1822

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

أود أن أرى تقاربًا بين مديري الحزم وليس تباعدًا.

كذلك هنا. على الرغم من عدم توافقهما في الوقت الحالي ، فقد حدث الاختلاف بالفعل ويسبب بالفعل احتكاكًا بالعديد من المستخدمين والمشاريع.

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

تؤدي إضافة الأخطاء الآن إلى تفادي مزيد من الالتباس ولا توقف الجهود في اتجاه التقارب.

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

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

لإضافة التوضيح ، حالة الاستخدام الخاصة بي على وجه الخصوص هي gatsbyjs. الوضع هو نفسه تمامًا كما أوردته gaearon هنا :

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

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

شكرا لكم جميعا على أرائكم.

jmorrell - https://github.com/yarnpkg/yarn/pull/5920 تم إصداره في 1.9.2 في 25 يوليو. مضى أكثر من شهر بقليل ، وأنا أعلم أنه ليس هناك الكثير من الوقت (وبالتأكيد ليس كذلك قام الجميع بالترقية) - ولكن هل لديك بعض الأفكار لمشاركتها فيما يتعلق بأخطاء ملف القفل المزدوج على Heroku منذ ذلك الحين؟

imsnif شكرًا على تذكير البريد الإلكتروني! آسف لفقدان التحديث هنا.

فيما يلي رسم بياني لعدد التطبيقات التي واجهت هذا الفشل المحدد كل أسبوع في 2018.

(لقد قمت بتنقيح مقياس y ، لكن هذا يمثل 100 من المطورين ويظهر الاتجاه)

1. يأتي الانخفاض في يوليو بسبب مشكلة غير ذات صلة مع S3

2. بالنظر إلى الاتجاه بعد 25 يوليو ، يبدو أن التحذير كان له تأثير كبير على عدد الأشخاص الذين واجهوا هذا الخطأ. أنا مندهش إلى حد ما من حجم التحول.

jmorrell - هذا رائع حقًا!
سوف أعترف أنني مندهش جدًا من هذا أيضًا.

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

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

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

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

ما لم يخبرني jmorrell بخلاف ذلك في الأسبوع المقبل أو نحو ذلك ،

imsnif أخذ مسارًا مختلفًا والنظر في الإخفاقات من سبتمبر حتى الآن (1 سبتمبر - 20 سبتمبر) ، لا يزال هذا هو السبب الأول الذي جعل Node يبني على فشل Heroku. يحدث هذا ضعف ما يحدث في حالة الفشل الأكثر شيوعًا التالية: يعتبر package.json غير صالح JSON. مرة أخرى تنقيح الأرقام الدقيقة ، إليك كيفية تكديسها مع المشكلات الأخرى.

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

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

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

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

jmorrell - نظرًا لأن هذه المشكلة تجذب الكثير من الاهتمام

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

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