Yarn: لا تحذر من التبعيات الاختيارية غير المتوافقة

يبدو أنه استخدام مناسب للتحذير لي.

ألن يكون من الأفضل إصلاح الشيء الذي يعطي التحذير بدلاً من إخفائه؟

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

ماذا تقصد ب "الإصلاح"؟ كما هو موضح في https://github.com/npm/npm/issues/11632 ، كل شيء يعمل على النحو المنشود. تعتمد بعض الحزم على fsevents على وجه التحديد على macOS (لأنها توفر تجربة متفوقة) ولكنها تعود إلى السلوكيات الأخرى في Windows / Linux. لا ينبغي أن تظهر حقيقة أن fsevents غير متوافق مع Windows للمستخدمين: إنها مجرد تفاصيل تنفيذ خاصة بالنظام الأساسي للتبعية. لا يوجد شيء عملي للمستخدمين هناك (ولا يوجد ما يدعو للقلق).

أود أن أقول إن طلب التبعية وإضافة الثنائيات لنظام تشغيل معين لا ينبغي أن يكون هو الطريقة التي يعمل بها.
أنا متأكد من أن هناك حزمًا أخرى تجعل هذه المشكلة منبثقة ، ولكن fsevents هي الأكثر شيوعًا ، حيث تواجه مشكلات في babel ، webpack ، create-react-app ، وأنا متأكد أنه قريبًا جدًا sane و jest . أعتقد أنه سيكون من الأفضل إيجاد حل أفضل لمشاهدة الملفات بدلاً من تغيير سلوك مدير الحزم بسبب عيوب حزمة واحدة.

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

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

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

jhabdas

ماذا عن العلاقات العامة لإضافة علامة CLI لمنعها حسب مستوى السجل

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

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

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

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

آسف إذا لم أكن واضحا جدا. أستطيع أن أرى الآن أن هذا مثير للجدل أكثر مما توقعت. دعونا لا نفعل هذا إذن. لن أموت على هذا التل. 😛

من ناحية أخرى ، فإن التحذيرات المماثلة ، مثل "هذه الوحدة لا تعمل على Node.js <4" ، مفيدة جدًا.

... ولكن هذا قابل للتنفيذ - يمكنك ترقية إصدار Node.js.

... ولكن هذا قابل للتنفيذ - يمكنك ترقية إصدار Node.js.

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

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

ربما يمكننا تخفيض هذا إلى مستوى سجل "معلومات" (وتقديم مفهوم مستويات السجل مثل npm).

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

أواجه موقفًا مشابهًا إلى حد ما كما وصفه gaearon : أتلقى تحذيرات بشأن التبعيات التي تستخدم

عندما أشغل yarn upgrade أحصل على هذا في البداية:

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

لكن عندما أنظر إلى القائمة التالية ، فإن تلك التبعيات محدثة.

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

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

يجب أن يعطي استخدام التبعيات غير الآمنة تحذيرًا.

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

wtgtybhertgeghgtwtg ما يلقي بي هو أن التحذير يطلب من _me_ تحديث شيء لا يمكنني تحديثه. على الرغم من أنني في هذه الحالة لست الشخص الذي يستخدم التبعية غير الآمنة (أعتقد أن Glob هي) ، إلا أنني أرى وجهة نظرك وأوافق على أنه يجب أن يكون تحذيرًا ؛ ولكن أعتقد أنه يمكن صياغتها لتكون أكثر إفادة. هناك شيء بسيط مثل "[التبعية_أ] تستخدم [تبعية_ب] قديمة" - سأعرف فورًا أن أ) ليس خطأ مني ، والخطأ ليس من جانبي ، و ب) أين أذهب لمعرفة ما إذا تم معالجة هذه المسألة. يمكن لهذا النوع من المعلومات أن ينقذ المستخدمين من النزول في حفرة الأرانب لمحاولة اكتشاف الخطأ من نهايتهم.

فكرة جيدة لتحسين الرسالة أولاً ، أرسل العلاقات العامة

في 7 يوليو 2017 الساعة 14:08 ، كتب Daniel Blake [email protected] :

wtgtybhertgeghgtwtg https://github.com/wtgtybhertgeghgtwtg ما رميات
أنا هو أن التحذير يطلب مني تحديث شيء لا يمكنني تحديثه.
على الرغم من ذلك ، في هذه الحالة ، لست الشخص الذي يستخدم التبعية غير الآمنة (I
أعتقد أن Glob هو) ، أرى وجهة نظرك وأوافق على أنه يجب أن يكون تحذيرًا ؛ لكن أنا
أعتقد أنه يمكن صياغتها لتكون أكثر إفادة. شيء بسيط مثل
"[تبعية_أ] تستخدم [تبعية_ب] قديمة" - سأعلم على الفور
الخفافيش أن أ) أنه ليس خطأي، والخطأ ليس في نهايتي و
ب) إلى أين تذهب لمعرفة ما إذا كان قد تم معالجة المشكلة. ذلك النوع من
يمكن أن تنقذ المعلومات المستخدمين من النزول إلى حفرة الأرانب لمحاولة اكتشاف ذلك
ما الخطأ في نهايتهم.

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

ما يلقي بي هو أن التحذير يطلب مني تحديث شيء لا يمكنني تحديثه.

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

بينما كنت سأجادل في ذلك

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

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

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

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

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

لا أريد أن يتحول هذا إلى جولة حول كل التحذيرات الممكنة.

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

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

عمال الصيانة ، الرجاء إغلاق هذا. لا يوجد أحد لمتابعة.

هل يمكنك تقديم حالتين مجانيتين للاختبار من فضلك؟

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

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

عمال الصيانة ، الرجاء إغلاق هذا.

jhabdas ، أنا أقدر وأشير إلى أن فريق Yarn لديه ما يكفي ، ولكن ليست هناك حاجة لتكرار ذلك. هذا ليس سلوكًا ودودًا للغاية.

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

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

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

سيؤدي تثبيت create-react-app ثم تشغيل create-react-app myapp إلى ظهور تحذير كجزء من التثبيت:

warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

تحذير npm أكثر ترويعًا:

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/react-scripts/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/react-scripts/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

لحسن الحظ ، يتيح لنا npm تحديد مستوى السجل ، وهو ما لا يسمح به Yarn. لسوء الحظ ، يتعين علينا تجاهل جميع تحذيرات npm بسبب هذا.

لماذا هذا التحذير مشكلة؟

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

إنهم لا يعرفون ما هو fsevents . تقرأ الرسالة كما لو أن Create React App غير متوافق مع Windows. هذا هو طعامهم. إنه لأمر رائع أن يعمل كل شيء لاحقًا ، ولكن إذا حدث شيء ما ، فلن يبلغوا دائمًا عن مشكلة لأنهم يدركون أنه ليس من المفترض أن يعمل بفضل هذه التحذيرات. أحاول محاربة هذا الانطباع من خلال هذا الاقتراح.

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

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

قد يبدو غير مرتبط بأدوات JavaScript ، لكنه في الحقيقة ليس كذلك. توجد مشكلتان منفصلتان هنا:

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

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

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

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

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

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

يقدم البحث السريع في Stack Overflow ، على سبيل المثال ، الحل التالي لمعالجة رسالة التحذير الموضحة: https://stackoverflow.com/a/42938398/712334.

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

@ glen-84 هل تهتم بمشاركة رأيك ، أم مجرد إلقاء إبهامك؟

بالتأكيد.

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

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

أوافق على أن التحذيرات غير القابلة للتنفيذ ليست مفيدة ويمكن أيضًا أن تكون مخيفة / مزعجة / بلا داع. دعونا نذهب معdmbdesignpdx الصورة الاقتراح كما اقترحbestander؟

ترحيب PR.

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

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

الوقت الضائع من قبل مطوري Yarn / npm ، مضطرون إلى شرح سبب حدوث ذلك

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

إذا جمعت الأصوات من مشكلة npm ، فسيوافق ما يقرب من 150 مستخدمًا.

هذا هو جدل ad populum. التصميم من قبل اللجنة لا ينجح أبدًا بشكل جيد لأي شخص.

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

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

إذا أراد أي شخص مناقشة المزيد حول هذه المسألة ، فلننقلها إلى Discord. يمكنك الاتصال بي هناك مباشرة لجذب انتباهي. 💓

تتعلم سبب حدوث ذلك وتتخذ إجراءً

ما هو الإجراء الذي يجب أن نتخذه؟

ليس من مسؤولية Yarn معالجة المشكلات من المستودعات الفردية أو مديري الحزم.

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

هذا هو جدل ad populum. التصميم من قبل اللجنة لا ينجح أبدًا بشكل جيد لأي شخص.

كل ما لدينا الآن ، وإذا كنت لا توافق على هذه التغييرات ، فإن تصويتك السلبي على المشكلة سيساعد المشرفين في اتخاذ القرار.

حسنًا @ glen-84 ذكرني أن المشكلة الأصلية لم تكن تتعلق بالتبعية الفرعية والرسائل الإعلامية ولكن ببساطة لم تحذر من حزمة لا يمكن تثبيتها على نظام أساسي معين.

لذا فإن الإجراء الخاص بهذه البطاقة المحددة هو ببساطة خفضها من تحذير إلى معلومات أو تصحيح أخطاء لأنها لا تضيف قيمة. اعتراضات؟ تم نقل الجزء الآخر إلى رقم 3869.

gaearon تم إجراء تغيير رمز سطر واحد بدون اختبار الوحدة لحل هذه المشكلة. من فضلك تذكر ذلك.

jhabdas لقد أجبت بالفعل في العلاقات العامة. هذه هي فلسفتي https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565 ، ولكن إذا كنت تعتقد أن توافق الحزمة أو هذا الجزء بشكل خاص يحتاج إلى بعض الاختبارات ، من فضلك افتح طلب سحب وشكراً مقدماً :)

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

jhabdas بقدر ما أقدر مساهماتكم ، أود أن أذكركم السلوك لدينا ، وتحديداً البنود التالية:

• استخدام لغة ترحيبية وشاملة
• احترام وجهات النظر والتجارب المختلفة
• إظهار التعاطف تجاه أفراد المجتمع الآخرين

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

شكرا لإصلاح هذا. 😍 🙇

لقد كانت القضية الأكثر تصويتًا في NPM بهامش كبير وتسببت في مشاكل حقيقية ، ولكن بعد 1.5 سنة من عدم معالجتها ، أغلقها الروبوت تلقائيًا لكونه قديمًا جدًا!

هذا النوع من إدارة المشاريع هو أحد الأسباب التي دفعتني إلى التحول إلى Yarn.

بالنظر إلى مدى سهولة الإصلاح ، فإنه من المؤلم مقدار الوقت والجهد الذي تم إهداره على هذا. 😢

شكر!

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

kubino هذه بعض التعليقات الرائعة ، شكرًا لك! نحن ندرك أن نقلها إلى info لن يصلحها مرة واحدة وإلى الأبد. لذلكjhabdas أنفقت بالفعل بعض الوقت لجعل أفضل وعامة و قدمت على RFC . هل أنت مهتم بتقديم ملاحظات هناك وإخبارنا إذا كان هذا RFC يعالج مخاوفك؟

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

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

على أي حال ، لم يكن لدي الوقت الكافي لقراءة طلب التعليقات هذا تمامًا حتى الآن ، لكنني أعتقد أنه يقع ضمن قسم label = "Interoperability" . ومع ذلك ، قد يتعين علينا إضافة قسم optimization لهذه الحالات. ومع ذلك ، دعنا نواصل المناقشة حول ذلك العلاقات العامة وأعتقد أنه يجب عليك تقديم هذا الاقتراح هناك ومعرفة ما يفكر فيه jhabdas حول ذلك.

kubino لقد قمت بتحديث وصف

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

كن سعيدًا لمناقشة واستخدام رؤيتك لزيادة تحسين RFC ، حيث تعلمت أن كونك أكثر خبرة يمكن أن يكون مسؤولية كبيرة أو أكثر حيث يمكن أن يكون أحد الأصول عندما يتعلق الأمر بالبرمجة.

BYK أعرف إلى أين تشير ؛) بالتأكيد أريد أن أتفق معكماjhabdas ، الحل العام هو السبيل الوحيد للخروج من هذه المناقشات. تصنيف الرسائل هو الخطوة الأولى التي ستمكن كل شيء آخر ... دعنا نواصل المناقشة في RFC ذات الصلة. شكر!

إذا كان الأمر اختياريًا "نظرًا لنظام تشغيل مستهدف" ، فلا ينبغي حتى أن يكون على مستوى WARN. يقول المؤلف "إذا كان MacOS فاستخدم FSEvents ، وإلا فلا تفعل". لذا إذا كنت تقوم بالتثبيت على نظام تشغيل آخر غير Mac ، فلماذا تحذر على الإطلاق؟ إنه أشبه بالمعلومات / التصحيح.

robertjchristian أعتقد أن هناك جانبين لهذا:

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

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

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

https://github.com/npm/npm/issues/11632#issuecomment -238217690

سيكون الحل هو إضافة دعم للتبعيات الخاصة بالمنصة.

https://github.com/npm/npm/issues/11632#issuecomment -257214969

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

https://github.com/npm/npm/issues/11632#issuecomment -300804918

إليك ما يمكن أن تفعله npm:

1. قم بتغيير التبعيات الاختيارية والرسائل غير المدعومة من WARN إلى INFO (ما يريده معظم الناس).
2. تنفيذ التبعيات الخاصة بالنظام الأساسي (حل مناسب)

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

  "conditionalDependencies": {
    {
      "condition": { "platform": "darwin" }, // 'darwin', 'freebsd', 'linux', 'sunos' or 'win32'
      "packages": { "fsevents": "^1.0.0" }
    }
  },

بديل آخر لمؤلفي fsevents:

اجعله لا يفشل على منصات غير OSX دون أي تحذيرات ، فقط رسالة INFO حول النظام الأساسي غير مدعومة

لكن هذا لا يختلف كثيرًا عن إخفاء التحذير على مستوى npm.

لا يزال هناك جواب؟ هذا التحذير مزعج للغاية.

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

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

إذا كنت تقوم بتطوير البرامج بشكل احترافي ، فلا يمكنني أن أوصي باستثمار أفضل.

لماذا تظهر تحذيرًا إذا كنت لا تطلب من المستخدم القيام بشيء لتصحيحه؟

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

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

في هذه المرحلة ، أميل إلى شراء جهاز Mac لغرض وحيد هو عدم رؤية ذلك

هل تقصد أنك لن ترى هذا على جهاز Mac؟
حسنًا ، لن تفعل ما لم تستخدم عامل الإرساء:

MacbookPro $ docker run -ti --rm node yarn add [email protected]
yarn add v1.13.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

أعتقد أنه سيكون لديك حظ أفضل عندما تفرغ chokidar وإزالة fsevents من هناك.
تحتوي العقدة الأخيرة على تحسينات رائعة بفضل دعم fs.watch الأصلي في OS X.

بالطبع ، سيتعين عليك أيضًا تفريغ عشرات الحزم اعتمادًا على chokidar

حاول تقديم شكوى هنا للتغيير:
https://github.com/paulmillr/chokidar/issues

أعتقد أنه سيكون لديك حظ أفضل عندما تفرغ chokidar وإزالة fsevents من هناك.
تحتوي العقدة الأخيرة على تحسينات رائعة بفضل دعم fs.watch الأصلي في OS X.

يبدو أننا في نفس الصفحة بعد كل شيء. وجه ضاحك

نعم ، أفترض أن الخيار الوحيد للانتظار حتى يسقط Chokidar دعم العقدة 10 ، وعندها يصبح عديم الفائدة وتبدأ المشاريع الأخرى في إسقاطه.

Vanuan دعم node.js الأخير fs.watch لا يزال هراء. حاول بالفعل استخدامه عبر الأنظمة الأساسية.

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

هل هذا فقط لن يتم إصلاحه؟