Yarn: أضف الحزمة دون حفظها في package.json

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

من إعلان الفيسبوك

لقد أزلنا سلوك "التبعية غير المرئية" لتثبيت npmوتقسيم الأمر. تشغيل yarn add <name> يعادل تشغيل npm install --save <name> .

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

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

نعم ، أعتقد أن السماح له بالقيام بعلم صريح سيكون أمرًا رائعًا ، حاليًا لهذا لا يزال بإمكانه استخدام npm i =) ولكن فقط للتخلص من حاجة npm.

نحن لا ندعم هذا بشكل صريح لأنه تغيير ضروري إلى node_module والذي سيتم مسحه مع yarn install s لاحقًا نظرًا لأننا نعتبر package.json و yarn.lock مصدر الحقيقة.

لدينا تبعية لا يمكن تثبيتها بسهولة على النوافذ (libxslt) لذلك:

• بالنسبة لنظام التشغيل windows: يقوم المطورون بفك ضغطه في node_modues
• بالنسبة لنظام Linux: يقوم المطورون بتثبيته بدون حفظ (إذا كان في package.json ، فلن يتمكن المطورون الذين يستخدمون Windows من إجراء أي تثبيت لأن البناء سيفشل)

هل هناك طريقة نظيفة للقيام بذلك باستخدام الغزل (أو أي طريقة أفضل لتحقيق هذه النتيجة)؟

(أتفق معك في أنه يجب أن تنعكس الحزم في الحزمة json ، ولكن هنا لا يمكنني العثور على أي حل نظيف)

GuillaumeLeclerc ماذا عن yarn add -D xxx وإزالة الإدخال من package.json بنفسك؟

سيتم إزالته في المرة القادمة التي يتم فيها إضافة حزمة أخرى؟ أليس كذلك؟

GuillaumeLeclerc للأسف ، نعم.

GuillaumeLeclerc قد ترغب في مسح تعليقك ...

الرجاء إضافة وسيطة مثل yarn add --no-save حتى أتمكن من تثبيت وحدة بدون تغيير package.json أو yarn.lock. غالبًا ما أجد نفسي بحاجة إلى اختبار الوحدات قبل الالتزام بها.

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

من فضلك لا تجعلني أعود التغييرات إلى package.json yarn.lock!

بالنسبة لي ، هذا يزعجني لأنني أحاول تثبيت peerDep. لا توجد طريقة لتثبيت خيوط النظير خلال install لذا يجب أن أقوم بذلك يدويًا. لا يمكنني yarn add <package> بدون إضافته إلى package.json / yarn.lock. انا عالق.

viveleroi هذا يبدو صحيحًا تمامًا. لماذا تريد تثبيت تبعية الأقران دون إضافتها إلى package.json ؟

hpurmann لأنه يقوم بتكرار peerDependencies إلى dependencies (أو devDependencies إذا كنت أستخدم --dev ). إذا كان هذا هو المقصود فهو بالتأكيد ليس بديهيًا.

hpurmann أريد نشر عنصر رد فعل ، لذا يجب أن يكون رد الفعل peerDep. ومع ذلك ، أحتاج إلى تثبيت رد فعل في المشروع لتطويره.

فقط أضف - no-save => إنه مهم جدًا
أحتاج إلى تخطي اعتماد اختياري معين لحزمة معينة. لا أستطيع أن أفعل ذلك مع خيوطك. قد يكون مع خيار - no-save I can work around

نظرًا لأن yarn link local-pkg لا يقوم بتثبيت تبعيات local-pkg في التطبيق المضيف ، أود تثبيتها مباشرة ولكن لا أحفظها في app package.json حيث سيتم إحضارها بواسطة local-pkg بمجرد نشرها .

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

أحاول استخدام Yarn لمشروع NodeJS الذي يتم تشغيله على AWS Lambda. أنا مندهش كيندا من سبب عدم دعم هذه الميزة. حالة الاستخدام الخاصة بي هي أنني بحاجة إلى تثبيت aws-sdk على بيئة التطوير المحلية الخاصة بي ، لكنني لا أريد حفظها في package.json لأن AWS Lambda قد تم تثبيتها بالفعل على بيئتها. تضمين aws-sdk يعني أن حزمتنا النهائية ستكون منتفخة.

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

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

كيف تحصل حول هذا؟

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

~ npm install [packages ...] --no-save --no-package-lock ~

كما هو مذكور

حسناً حتى الآن لا أستطيع العيش بدون npm بعد ذلك

كنت أستخدم npm install في أحد البرامج النصية الخاصة بي والتي تقوم بتثبيت تبعيات الوحدات الفرعية المحلية على وحدات node_modules الرئيسية. يعمل هذا بشكل جيد مع npm4 ، ولكنه معطل تمامًا مع npm5 ، حيث قرر npm5 فقط تفجير بعض الحزم أثناء التثبيت -.- (انظر https://github.com/npm/npm/pull/18921)

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

لديك بالفعل خيار --no-lockfile ، لذا فهو يجعل مجلد node_modules بعيدًا عن التفكير ،
ولكن لا تزال المطورين بحاجة إلى حلول بديلة للحفاظ على package.json غير قابل للتغيير.

شكرا لك.

يعجبني كيف في كل مرة يشرح فيها شخص ما حالة الاستخدام الخاصة به لتثبيت وحدة ما ولكن دون تسجيلها ، يعود المشرفون ويقرأون رموزهم. يجب أن تجعل من السهل الشعور بالثقة في عنادك إذا كان بإمكانك تلبية هذا الطلب نفسه من العديد من الأشخاص المختلفين على أنه يأتي من أولئك الذين يعانون من فشل أخلاقي. كحل وسط ، ربما يمكننا تسمية المحول --i-am-a-heritic-and-a-bad-programmer ؟

من المحزن أن نرى العيب الرئيسي الوحيد yarn المحفوظ من npm هو عداءه لأي شخص خارج مؤسستهم.

وفي حالتي أردت استخدامه كحل بديل لمشكلة # 4297 :)
قد يؤدي تقييد المطورين بشكل مصطنع للقيام بالأشياء إلى جعل منتجك غير قابل للاستخدام في مواقف معينة.

انتظر هل تمزح معي؟ هذه مهزلة. يرجى التوقف عن إملاء كيفية عمل كل مطور على الإطلاق. هذا هو بالضبط السبب في أن NPM لم يناسبنا وانتقلنا إلى Yarn. هذه الأيديولوجية القائلة بأن "package.json و yarn.lock يجب أن يكونا مصدر الحقيقة" هي هراء. يجب أن تكون الحزم قابلة للتثبيت بدون تعديل كود المصدر. سهل هكذا.

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

وجدت الآن أن yarn يكسر اختباراتي لأن لديّ وحدات أحتاج فيها إلى اختبار require ومن أجل الاختبار ، يجب أن أقوم بتثبيت نموذج في ./node_modules . يقوم Yarn بحذف نماذج الوحدات النمطية عند تشغيل yarn install . أفترض المزيد من "مصدر الحقيقة" التحذلق.

استخدام القضية: استخدام أداة I يتطلب حزمة. لا يستخدم الفريق هذه الأداة. لا يريد الفريق (بشكل مبرر) تثبيت هذه الحزمة.

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

إنه 2018 بالفعل ولكن لم تتم إضافة هذه الميزة حتى الآن على الرغم من العديد من حالات الاستخدام الصالحة.

فقط لإعطاء مثال آخر لماذا قد يكون هذا مفيدًا:

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

علاوة على ذلك ، من الأنظف ألا تغير وجهة نظرك الوحيدة ( package.json ) قبل أن تتأكد "تمامًا" من قدرتك على تحديث هذه التبعية دون كسر أي اختبار. في الوقت الحالي ، ينتهي بك الأمر بـ package.json (حتى لو كان مؤقتًا) يحتوي على تبعية تكسر شفرتك.

هناك العديد من حالات الاستخدام الصالحة لهذه المشكلة. هل سيكون القائمون على صيانة yarnpkg على استعداد لقبول العلاقات العامة إذا تم إنشاؤها؟

pinging @ kittens إذا كنت لا تزال تابعًا لهذا المشروع ...

في هذه الأثناء ، أستخدم النص التالي في قسم scripts في package.json :

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

أفترض أن هناك بديل للغزل؟

لا يوجد بديل ، npm5 فوضوي مثل حياتي.

ولا تنس نسخ الروابط الرمزية في مجلد .bin. ؛)

بالنسبة لي ، يعمل chmod 444 package.json و yarn add XXXX --no-lockfile على الأقل على حل مشكلة التطوير المحلي والاختبار.
تنتهي الإضافة بخطأ إذن (متوقع) ، ولكن الوحدة المضافة موجودة في node_modules بعد ذلك ، وأنا قادر على الاختبار باستخدام تبعيات الأقران المثبتة محليًا ولكن لم تستمر في package.json ولكن كاعتماد على الأقران.

أحتاج أحيانًا إلى مكتبة تصحيح أخطاء مؤقتًا ، مثل why-is-node-running . أعلم أنني أريد التخلص منه بعد استخدام واحد ، وسيسمح لي خيار --no-save بالتثبيت والنسيان ، دون المخاطرة بتلويث تبعياتي.

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

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

بدلا من:

git clone external-package (needed for temp testing only)
yarn install
yarn link

العودة إلى الريبو الأصلي الخاص بي
yarn link external-package

مجرد:
الأصلي- الريبو:
yarn install external-package --no-save

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

لا أفهم لماذا يجب أن ينعكس تثبيت هذه الأداة البسيطة في قائمة الحزم ، فهذا يعني فقط أنني بحاجة الآن إلى إجراء git checkout ${BRANCH_NAME} للتراجع عن التعديلات قبل أن يمكنني دفع العلامات.

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

اي فكرة لماذا تم اغلاق هذا الموضوع؟ هل تمت إضافة مفتاح التبديل --no-save في العلاقات العامة؟

هناك أوقات أرغب في تغيير إصدار الوحدة التي يتم إحضارها من تبعية. على سبيل المثال ، تم جلب @types/sinon بواسطة تبعية مطور أخرى أدت إلى كسر tsc مؤخرًا. لا أريد @types/sinon إلى تبعيات مطوري البرامج ، لكنني أريد تغيير الإصدار يدويًا باستخدام yarn add @types/[email protected] --no-save حتى أتمكن من مواصلة العمل. بدلاً من ذلك ، أعود إلى npm. محبط للغاية.

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

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

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

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

هاها ، ما زالت لم تنفذ ، نيييس

لماذا تريد وجود مثل هذا الشيء؟

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

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

الحيلة العملية هي yarn add --dev pkg && yarn remove pkg . وهو يفعل الشيء نفسه. يظل ملف القفل كما كان من قبل ، ولم يمسه أحد.

تم ذكر ذلك من قبل @ Legends في وقت سابق ولكن يجدر التأكيد:

أحد الحلول لبعض الحالات هو تثبيت الحزمة المطلوبة في مجلد منفصل و yarn link الحزمة المطلوبة إلى أي مكان كان من الممكن إضافته. إنها ليست مثالية ولكنها يمكن أن تساعد.

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

silentorb بالتأكيد لا يستحق ، imho. add + remove هو بالضبط ما يتم عمله مع --no-save في npm. لا يعبث بروابط النظام ولا يلمس ملف القفل بطريقة سيئة - مما يعني أنه هو نفسه بعد yarn remove .
ناهيك عن أنه إذا كنت تريد القيام بهذا الشيء برمجيًا ، فمن المؤكد أن إنشاء dirs والربط وما إلى ذلك ليس هو السبيل للذهاب.

بعض الحالات

فمثلا؟ غريبة جدا بالتأكيد؟

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

إذن ما هي الممارسة الموصى بها لتطوير حزمة مع تبعيات الأقران؟

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

بالنظر إلى https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json أعتقد أن الإجابة هي نعم

@ 18steps تحقق من https://www.npmjs.com/install-peers

هناك بعض المواقف لاستخدام هذه الميزة.

كما هو الحال في دورة حياة CI ، أضفت بعض مراسلي التغطية. لكن لا يمكنني إحضارهم إلى package.json ثم يؤثر على نشر NPM .

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

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

(عذرًا ، انتهى هذا الأمر لفترة أطول مما كنت أقصده).

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

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

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

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

ومع ذلك ، يمكنني رؤية عدة أسباب لتقديم تنازلات:

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

• هناك حلول يمكن إيجادها قد تعمل مع الجميع. على سبيل المثال ، قم بتقديم ملف جديد yarn.local.lock . سيضعها المطورون في .gitignore ، وسيحتفظ بسجل لجميع الحزم المثبتة بعلامة --no-save وتبعياتها.

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

  باستخدام هذا الحل ، يمكن لـ Yarn متابعة تتبع جميع الحزم ، ويمكن للمطورين تثبيت العناصر دون تلويث الريبو الخاص بهم ، ونحن نحتفظ بالبنيات القابلة للتكرار. (هناك أيضًا مساحة لـ package.local.json مع قسم devDependencies ، لكنني لست متأكدًا من أنه سيكون مطلوبًا.)

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

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

لدي حالة استخدام أخرى: أود أن تكون الوحدة متاحة في REPL ولكن لا أنوي استخدامها في الكود الخاص بي. في الوضع الحالي ، أحتاج إلى الانتقال إلى مجلد مختلف وتثبيت هذه الوحدة هناك ، ثم استيراد بعض ملفات json باستخدام ../other-project/data/xyz.json .

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

مجرد السماح لي بتثبيت وحدة نمطية في node_modules بدون حفظ سيجعل الأمر أسهل كثيرًا.

أنا مندهش من مدى مقاومة المشرفين لهذه الفكرة.

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

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

الحل الوحيد الذي وجدته هو تثبيت peerDepencies كـ devDependencies والذي لا يبدو أنه مثالي على الإطلاق ، لكنه يعمل على حل المشكلة. على الأقل npm في حالته الرهيبة للتثبيت بدون تعديل ملف package.json .

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

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

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

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

لا أستطيع أن أقرر أي شيء رغم ذلك. أنا لست مشرفًا على هذا المشروع.

Vheissu ما هي المشكلة مع yarn add --peer <dep> ؟

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

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

تمامًا مثل @ brendan- Hurleysuyanhanx ، لدي تبعيات أريد تثبيتها في CI وليس محليًا.
أريد أن أبقي تبعياتي المحلية عند الحد الأدنى حتى لا نضطر إلى تضخيم node_modules وتكلفنا الوقت والمساحة لكل مطور يعمل في المشروع.

الحزم المطلوبة في CI ولكن ليس محليًا:

• أدوات خاصة بـ CI: ملف إطلاق الدلالي ، ملف Greenkeeper-lock
• أدوات الإبلاغ عن التغطية: تغطية التشفير ، المعاطف
• أداة الإبلاغ عن الاختبار لـ CI: jest-junit ، إلخ.

هذا هو سبب حاجتنا إلى هذه الميزة:

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

إما أن يضيف yarn link تبعيات أو يوفر طريقة لاستبعاد الوجهة package.json

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

ومع ذلك ، أتمنى لو أن yarn سيثق بي لأعرف ما أفعله ويسمح لي بتمرير العلم --no-save . إذا واجهت أيًا من حالات المشاكل ، فسأعرف بالضبط الخطأ الذي حدث ، وأنني لا ألوم سوى نفسي. :ابتسامة:

حالة الاستخدام الخاصة بي؟
أقوم بتشغيل آلة فوز 64 بت.
آلة همز 32 بت.

تبعية Node-sass لدينا تدعم 32 بت فقط ما لم نحدّث الحزمة.

عدم تغيير التبعية في package.json أو yarn.lock لدعم آلة التطوير.
لذلك ترغب في تثبيت أحدث node-sass محليًا لدعم 64 بت ، ولكن لا يؤثر على package.json و yarn.lock

أرغب في تثبيت حزم @types/* لمشاريع ليست من نوع TypeScript دون تلويث package.json / yarn.lock لإكمال تلقائي أفضل في VSCode

أنا أستخدم lerna مع مساحة عمل الغزل.
يتعطل تعريف نوع Antd بسبب تحديث @ أنواع / رد @
Antd سوف يصلح هذا في نهاية الأسبوع.
لكنني الآن بحاجة إلى إجبار الخيوط على تثبيت إصدار ثابت من @ types / رد @

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

يؤدي تحديث الحزمة ضمنيًا والحفظ الضمني في package.json إلى حدوث تعارض.

إليك حالة استخدام أخرى. أنا أحافظ على مكتبة React. قبل نشر إصدار جديد ، أريد إجراء اختباراتي مقابل إصدارات متعددة من react و react-dom ، للتحقق من أن التغييرات التي أجريها متوافقة مع الإصدارات السابقة والأمامية ( @next ). كنت أفعل ذلك باستخدام الإعداد أدناه ، لكنني الآن أريد استخدام مساحات عمل Yarn لذلك أحتاج إلى الانتقال إلى Yarn.

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

لا يمكنني جعل هذا البرنامج النصي يغير package.json لأن ذلك سيجعل أمر النشر الخاص بي ( pack publish ) يفشل بسبب التغييرات غير المرحلية.

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

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

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

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

هل تمزح ؟ 3 سنوات لإضافة مفتاح بسيط؟

حالة استخدام أخرى: نستخدم حزمة npm ( git-hoooks ) لعمليات التحقق من الالتزام المسبق. ليس كل فرد في الفريق لديه عقدة مثبتة ، لذا فإن تضمينها في package.json سيؤدي إلى كسر الالتزامات لبعض الأشخاص. لذلك أحاول إنشاء برامج نصية npm لتمكين / تعطيل الخطافات بشكل عابر عن طريق تثبيت / إزالة git-hooks. محبط للغاية لمعرفة أن هذه المهمة التي تبدو بسيطة وسهلة يكاد يكون من المستحيل إنجازها باستخدام الغزل.

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

هل تمزح ؟ 3 سنوات لإضافة مفتاح بسيط؟

spanasik و Ryuurock : يرجى أن تكون مهذبًا عند مناقشة البرامج عالية الجودة التي يتم توفيرها لك مجانًا.

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

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

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

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

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

طرق بناءة للمضي قدمًا:

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

الحيلة العملية هي yarn add --dev pkg && yarn remove pkg . وهو يفعل الشيء نفسه. يظل ملف القفل كما كان من قبل ، ولم يمسه أحد.

تم اختباره - لا يعمل.

حالة الاستخدام الخاصة بي هي كما يلي:
تحتوي بعض الحزم على إضافات اختيارية يتم تحميلها بـ "تتطلب". لا أرغب في إضافة هذه الوظائف الإضافية إلى قسم devDependencies لذلك أقوم بـ "yarn add my add-in" وقم بإزالته يدويًا من ملف package.json. في خط أنابيب Cloud CI الخاص بي ، أستخدم "npm i" لإضافتها (للاختبار). لا أريد استخدام npm في خط الأنابيب المحلي الخاص بي لأنه ينشئ ملف قفل إضافي. أفضل خيار لدي الآن هو استخدام npm ثم حذف ملف القفل الخاص بهم (لإزالة الإصدار الثاني الظاهر من الحقيقة).

إذن بعد قراءة كل شيء ، سؤالي للمشرفين هو:

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

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

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

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

يوم الأربعاء 15 يناير 2020 الساعة 23:17 هاجيمي ياماساكي فوكيليتش <
[email protected]> كتب:

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

الإيمان بالقواعد المثالية وأنه لن تكون هناك فرصة أبدًا لذلك
كسر لهم هو ساذج. هناك فرق بين "أفضل الممارسات" و
"إفعل أو مت". كما قال أوليفر ويندل هولمز الأب:

الشاب يعرف القواعد لكن العجوز يعرف الاستثناءات.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/yarnpkg/yarn/issues/1743؟
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

اصنع مدير الحزم الخاص بك ، فلا أحد يجعلك تفعل أي شيء.

لست غاضبًا على الإطلاق ، فقط أشر إلى الخطأ في منطقك:

الغزل يجعلني أعمل بطريقة معينة.

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

foxbunny أنا أقدر لك توضيح

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

whitecolor الفريق قد حصل على نقطة. هذا الخيار - الحفظ غبي. تتوازن ضمانات الغزل بين node_modules و package.json وملف القفل وهذا شيء رائع. هذا أكثر أمانًا .... الحفظ npm خطير. لقد خذلتني مرات عديدة

أرجوك توقف

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

حالة الاستخدام الخاصة بي هي

أريد تحديث التبعية الفرعية لتطبيقنا
أنا أربط هذه التبعية بـ yarn link
ثم أستخدم واحدًا مرتبطًا في تطبيقنا
أضفت بعض التبعية في مكتبتنا
لم يتم تثبيت تبعية lib المضافة في التطبيق الرئيسي بعد yarn install (wtf no.1)
ثم أعتقد ، حسنًا ، دعنا نضيفه بسرعة دون الحفظ في التطبيق حتى أتمكن فقط من التحقق مما إذا كانت الأشياء تعمل قبل أن أنشر التحديث على موقعنا
لكن - كلا.

شكر

آسف لرؤية المجتمع تجاهل من قبل المؤلفين.

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

يوم الثلاثاء 3 مارس 2020 الساعة 03:53 أرتور كوياتكوسكي إخطارات @github.com
كتب:

آسف لرؤية المجتمع تجاهل من قبل المؤلفين.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/yarnpkg/yarn/issues/1743؟email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW13
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

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

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

أنا أميل إلى الاتفاق مع المشرفين هنا:

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

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

لقد أنشأت yarn-add-no-save لتحقيق هذه الوظيفة. يمكن تثبيته محليًا لمشروعك أو عالميًا:

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

بمجرد التثبيت ، يمكنك ببساطة تشغيل:

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

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

$yarn add-no-save --help

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

هذا مفيد للغاية ، وخاصة دعم peerDeps. شكرا لك.

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

لا بد لي من yarn install xxx ثم yarn remove xxx .

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

لا بد لي من yarn install xxx ثم yarn remove xxx .

نفس الشيء

إليك حالة استخدام للرغبة في القيام بذلك:

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

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

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

قبل أن أقرأ رد "المشرفين" هنا ، اعتقدت أنني أكثر شخص عنيد على الإطلاق.

قرابة 4 سنوات ... 🤦

"العناد" ليس هو نفسه "امتلاك رؤية تصميمية وعدم تنفيذ كل ما يطلبه أي شخص".

"العناد" ليس هو نفسه "امتلاك رؤية تصميمية وعدم تنفيذ كل ما يطلبه أي شخص".

تصف رؤية التصميم المسار السعيد ، وتضيف بوابات الهروب كما هو مطلوب هنا ، إضافة إلى الفائدة للمجتمع الأوسع.

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

حل Git هذه المشكلة قبل عقود من الزمن ، لحق بها! مجرد الخروج بشيء! هذا هو التصميم - الالتفاف على القيود ، بدلاً من محاربتها (أو الاستسلام لها).

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

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