Yarn: أضف وسيلة لتثبيت اعتماديات نظير الحزمة من أجل التطوير / الاختبار

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

npm install
سيتم تثبيت جميع الحزم المعلنة في قسم التبعيات package.json.

yarn add --peer
كنت أتوقع أن يقوم هذا بتثبيت جميع الحزم المعلنة في قسم package.json peerDependencies.

هل هناك طريقة لتثبيت حزم معلنة في peerDependencies؟

حالة الاستخدام الخاصة بي هي تطوير / اختبار وحدة أصلية للتفاعل.

إليك مشكلة NPM ، التي أغلقوها: https://github.com/npm/npm/issues/11213

على ما يبدو ليس مهمًا لمطوري NPM.

1+ هذا مهم لمؤلفي المكتبة

لقد كتبت هذا بالفعل عن قضية NPM ، ولكن بالنسبة لأشخاص الغزل:

لقد كتبت برنامج cli لتثبيت تبعية الأقران للحزمة:

# If you're using npm
npm install -g install-peerdeps

# If you're using yarn
yarn global add install-peerdeps

cd my-project-directory

install-peerdeps <package>[@<version>]

# for example
install-peerdeps @angular/core
# will install all of angular's peerdeps

إذا كان لديك أي مشاكل في ذلك ، يرجى فتح مشكلة في الريبو!

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

لقد أصلحته بحزمة للقيام بذلك https://www.npmjs.com/package/@team-griffin/install -self-peers

nathanhleung أيها الصخور.

حسنًا ... إذا احتاج المرء إلى التبعيات من أجل التطوير / الاختبار ، ألا ينبغي لأحد أن يضعها تحت devDependencies ؟ لا تحاول إلقاء قنبلة أو أي شيء ...

nikolakanacki @ انظر تمامًا من أين أتيت ، وأعتقد أن الغرابة هي أنها ستعتمد على الأقران والاعتماد على التنمية ، حيث لا يجب أبدًا إجبار المستهلكين على تثبيت تبعيات مطوري البرامج. أنا أصوت لتسهيل تثبيت أقرانهم!

nikolakanacki إذا قمت

استخدم قواعد eslint-find-rules

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

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

عندما يقوم المستخدم بتشغيل yarn ، يجب ألا يقوم النظام بتثبيت أقسام النظير والتحذير من فقدهم (هذا يعمل).

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

نقطة مثيرة للاهتمام

• yarn add <package> --peer بتثبيته على node_modules وإضافته إلى package.json
• yarn add <other_package> بعد ذلك يزيل الحزمة المثبتة من node_modules

أنا حاليًا أتابع نموذج yarn install --peer لتثبيت dependencies و devDependencies و peerDependencies لكن هذا يعمل جيدًا بالنسبة لي.

إذا حصلت على هذا الحق kyleholzinger / gaastonsr ، فأنت لا تتطلع إلى تثبيت peerDependencies في وضع التطوير ( cd -ed في الريبو / الحزمة التي تحتوي على peerDependencies ، استنساخ جديد ، تحتاج إلى التطوير على هؤلاء النظراء) ولكن قم بإضافتهم إلى المشروع المستهدف بمجرد تثبيت الحزمة التي تحتوي على أقسام النظراء؟

للتوضيح: قمت بتثبيت eslint-find-rules الذي يشكو من أنك تحتاج eslint كإعالة (إنها peerDependency من eslint-find-rules ) ، لذا الآن تريد طريقة سهلة من إضافة تلك التبعيات في peer الذي تعمل عليه (المشروع الحالي الذي يعتمد على eslint-find-rules )؟ شيء مثل "حل وإضافة تبعيات جديدة (تعديل package.json و yarn.lock ) أفضل تبعيات الأقران المطابقة التي تتطلبها تبعياتي الحالية"؟

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

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

شيء للتفكير فيه بالتأكيد.

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

هذا ما أبحث عنه. تثبيت peerDependencies عندما أقوم بتطوير حزمة.

نعم بالضبطnikolakanacki! أشعر أن هناك فرصة عظيمة لنا لمساعدة الناس في إدارة أقسام نظرائهم.

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

سؤالان بسيطان وغير مرتبطين تمامًا يجب على المرء طرحهما قبل تثبيت التبعية المذكورة في حالات مثل هذه:

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

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

nikolakanacki عندما نبني أضفناها كـ devDependency ، فسنقوم حتماً بتثبيت إصدار مختلف وسيتم استخدامه بدلاً من إصدار المستخدم.

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

ليس الأمر كذلك حاليًا:

• https://github.com/yarnpkg/yarn/issues/3793
• https://github.com/yarnpkg/yarn/issues/3778

alexilyaev أعتقد أن nikolakanacki يعني تثبيته على حد سواء كاعتماد على الأقران و devDependency.

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

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

ليس أقل من devDependency لا علاقة له به ، فهو الذي يتم تثبيته عند تشغيل yarn أو npm install داخل الحزمة المصدر (الحزمة التي تعلن عن تبعية الأقران ، على سبيل المثال : ملحق) ، ولا تتم استشارته حتى عند استخدام الحزمة من قبل حزمة / مشروع طرف ثالث (نظير).

النقطة المهمة هي: لا أرى مدى صلة كل هذا؟

أستطيع أن أرى الألم الناجم عن إبقائهم متزامنين ، ولكن يمكنك بسهولة كتابة نص برمجي bash / javascript / <whatever> للتحقق من ذلك كخطوة ما بعد التثبيت في package.json .

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

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

nikolakanacki لنفترض أن المكوِّن الإضافي الخاص بي يقبل ^7.0.0 وآخرها هو 7.9.0 والمستخدم المحدد في package.json 7.4.0 .
إذا كان لدي ^7.0.0 في devDependencies أيضًا ، ألن يتم تثبيت Yarn (للمستخدم) كلاً من 7.9.0 و 7.4.0 ؟

إذا كان الأمر كذلك ، فقد يستخدم المكون الإضافي الخاص بي عن طريق الخطأ 7.9.0 بدلاً من 7.4.0 .

alexilyaev ستستخدم الحزمة الخاصة بك دائمًا ، مثل أي حزمة أخرى في أي حالة أخرى ، أعلى إصدار متاح يلبي "نطاق semver" المحدد في الحزمة الخاصة بك لهذا القسم النظير.

سأكون أكثر تحديدًا ولكني لا أفهم تمامًا الحالة التي قدمتها ، هل يمكنك التوضيح؟

~ سيحذرك من أن لديك peerDependency غير متوافق ، يتوقع المكون الإضافي الخاص بك ^7.0.0 ولديك الإصدار 7.4.0 . ~ تم التحديث: ^7.0.0 يرضي 7.4.0 .

لن يتم تثبيت الغزل (للمستخدم) 7.9.0 و 7.4.0؟

لا يقوم Yarn بتثبيت peerDependencies أجلك ولن يقوم بتثبيت devDependencies من المكون الإضافي الخاص بك فقط التبعيات في dependencies .

gaastonsr أنت محق تمامًا باستثناء أن ^7.0.0 راضٍ عن 7.4.0 .

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

تم شرح نطاقات Semver بواسطة npm: https://docs.npmjs.com/misc/semver
عندما تكون في شك ، تحقق دائمًا من: http://jubianchi.github.io/semver-check/

nikolakanacki @ لتتمكن من تثبيت حزم اعتماد الأقران بسهولة سيكون أمرًا رائعًا!

nikolakanacki حسنًا ، لذلك عندما يقوم المستخدم النهائي بتثبيت الحزمة ، لا يتم تثبيت devDependencies ، لذلك يجب على مؤلف الحزمة إضافة peerDependencies إلى devDependencies أيضًا.

لذلك ، هذا يحل مشكلة التنمية المحلية.

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

لذا ... أقترح الاستمرار في دعم طريقة لتثبيت تبعيات الأقران ، على الأقل حتى لا نضطر إلى استخدام install-peerdeps بعد الآن.

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

nikolakanacki الحل منطقي تمامًا. هذا ما نستخدمه لتطوير مكتبتنا. تحتاج إلى إعداد devDependencies بشكل صحيح في المكتبة للاختبار المعزول (خارج مشروع مضيف يوفر peerDependencies المطلوب) وتحتاج إلى peerDependencies للاختبار المتكامل ولضمان المضيف لا ينتهي المشروع بتثبيت حزم مكررة / مكررة لأن المكتبات التي يستهلكها تستخدم نفس dependencies و _ لا تستخدم بشكل مناسب peerDependencies و devDependencies .

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

ما الحل؟

لقد مررت عبر التعليقات بسرعة كافية ولم ألاحظ حلًا بسيطًا:

يرجى دائمًا تثبيت peerDependencies على أنها تبعيات عادية ، إذا كانت في حزمة المستوى الأعلى

يناسب تمامًا حالات التطوير / الاختبار ولا يؤثر على تثبيت الحزمة كتبعية. على غرار المنطق لدينا ل yarn.lock. ليست هناك حاجة لمزيد من "التطوير" أو أي طريقة أخرى.

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

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

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

لا تتردد في إعادة الفتح مع توضيح أو تقديم خطأ جديد.

BYK هل أنت متأكد حقًا من أنك تفعل الشيء الصحيح لإغلاق المشكلات مع 55 إعجابًا و 34 تعليقًا فقط لأنه ليس واضحًا لك؟

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

ستؤدي إضافة تبعيات الأقران أيضًا باعتبارها تبعيات dev ، كما هو مقترح في الأعلى في هذا الموضوع ، إلى كسر التدفق المكتوب: https://github.com/flowtype/flow-typed/issues/379

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

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

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

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

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

jimsugg ، لقد كنت أستخدم yarn add <package...> -p لتثبيت تبعيات الأقران يدويًا المدرجة بالفعل في package.json ، وهو بالتأكيد مضاد للنمط. يبدو أنه يجب تثبيت تبعيات الأقران تلقائيًا في بيئات التطوير (إذا كانت في الواقع تبعية للأقران ، فيجب على الأقل أن تكون هناك اختبارات تتطلب الحزمة).

كنت أبحث عن نفس الشيء وتوصلت إلى Bash one-liner لتثبيت جميع أقسام النظراء المدرجة (يتطلب منك تثبيت jq): yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json) .

آمل أن يساعد هذا شخص آخر.

EdwardDrapkin شكرا على تلك الفكرة الأسطورية! لقد قمت بتوسيعه وانتهى بي الأمر بإضافة برنامج نصي npm للقيام بذلك:

"install:peers": "yarn add -P $(jq -r '.peerDependencies | to_entries | map(\"\\(.key)@\\(.value | tostring)\") | join(\" \")' package.json)",

ما عليك سوى الاحتفاظ بمواصفات الإصدار من peerDependencies أيضًا ؛) إذا كنت لا تريد استخدام علامة latest ، إلا إذا كنت لا تريد استخدام علامة أخرى مثل next أو شيء من هذا القبيل.

shousper هذه طريقة بدون التبعية jq :

node -e "const peers = Object.entries(require('./package.json').peerDependencies || {}).map(d => d.join('@')).join(' '); if (peers.length) process.stdout.write('yarn add -P --no-lockfile ' + String(peers));" | sh

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

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

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

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

peerDepdency: رد @ ^ 16.0.0
devDependency: رد فعل~16.1.0

من شأنه أن يحد من التثبيت المحلي لـ response إلى 16.1.0 تقريبًا ، لكن مع السماح بأي إصدار v16 كاعتماد على الأقران. لست متأكدًا تمامًا من المكان الذي سيكون فيه شيء من هذا القبيل ضروريًا ، لكن لا يبدو أنه غير صالح.

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

bdwainkyleholzinger أنا لا أوافق ، لأن الغرض من peerDependencies هو الإبلاغ عن الحاجة إلى التبعية ، وليس توجيه الإجراء الفعلي لتثبيت التبعية.

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

إن نقص الدعم هنا في سياق الغزل هو القدرة على تحديد كل من قسم النظير والتطوير ، كما هو موضح هنا .

ومع ذلك ، للالتزام بمواصفات التثبيت الافتراضية لمديريات النظراء ولتوفير تجربة مطورة أفضل ... ربما يمكن للغزل تقديم خيار --include-peers لأمر التثبيت؟

hulkish بينما أتفق مع المشاعر ، متى سيكون مثالاً عندما تريد إعلان شيء ما على أنه تبعية للأقران ، ولكن _لا_ على أنه تبعية مطور؟

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

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

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

hulkish على الرغم من أنني أتفق مع المشاعر ، فمتى سيكون مثالاً عندما تريد أن تعلن عن شيء ما على أنه تبعية للأقران ، ولكن ليس تبعية ديف؟

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

أعتقد أن الحل هنا هو أن يقدم الغزل خيارًا يتيح تثبيت الأقران تلقائيًا. كن عينيًا أن الفائدة الأساسية من استخدام تبعيات الأقران هي اكتساب الرؤية عند استخدام تبعيات عابرة غير متوافقة. المفتاح هنا هو عدم كسر السلوك الافتراضي لمديريات النظراء عند التثبيت.

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

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

عندما لا تحتاج إليها لإجراء اختبارات الوحدة أو البناء

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

كن عينيًا أن الفائدة الأساسية من استخدام تبعيات الأقران هي اكتساب الرؤية عند استخدام تبعيات عابرة غير متوافقة

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

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

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

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

أنا أتحدث بشكل خاص عن الوقت الذي تقوم فيه بـ yarn install عند تطوير وحدة نمطية مع تبعيات الأقران ، وليس عند إضافة وحدة مع تبعيات الأقران إلى مشروع آخر

bdwain ليس بالضبط ، إنه بالتأكيد شيء زلق

حالة الاستخدام مع المشكلة

لنفترض أن هذه هي حزمة المستوى الأعلى لديك:

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

ثم ، foo / package.json:

  "dependencies": {
    "react": "^16.0.0"
  }

وفقًا لشجرة التبعية هذه ، عند تشغيل تثبيت yarn / npm ، سيبدو node_modules dir كما يلي:

node_modules/
  react/ <-- @^15.0.0
  foo/node_modules/react/ <-- @^16.0.0

في هذه المرحلة ، ما لم تقرر (لأي سبب كان) فحص بنية dir المتداخلة node_modules - فلن تعرف أبدًا أن هناك مشكلة. هذا ليس خطأ مدير الحزم - لقد أكمل وظيفته بدقة.

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

استخدم الحالة مع حل peerDependencies

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

ثم ، foo / package.json:

  "peetDependencies": {
    "react": "^16.0.0"
  }

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

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

أتمنى أن يفسر هذا الأمر بشكل أفضل.

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

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

أنا أفهم. أعتقد أن السلوك الافتراضي لقسم النظراء يجب أن يظل كما هو. لكن ، أعتقد أن الحل السهل هو السماح لهذا بأن يكون قابلاً للتكوين عبر cli و / أو env vars و / أو .yarnrc . شيء مثل --install-peers-as-dev

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

ولكن ، أعتقد أن الحل السهل هو السماح لهذا بأن يكون قابلاً للتكوين عبر cli و / أو env vars و / أو yarnrc. شيء من هذا القبيل - install-peers-as-dev

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

kyleholzinger هذا مكان جيد للبدء https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58

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

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

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

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

وإضافتها تلقائيًا إلى كل من dev و peer لا تزال تواجه مشكلة تكرار التبعية في مكانين ، والتي تعد IMO مشكلة ويجب ألا تكون ضرورية.

وفي كلتا الحالتين ، يجب الإبلاغ عن هذه التحذيرات / الأخطاء.

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

biels نفسه! أنا فعلا نسيت تماما قلت انني ستعمل العمل على هذا حتى لم تكن قد بدأت بعد، سأحاول أن العمل على ذلك عندما استطيع ان على الرغم من ذلك يمكننا على الأقل أن يكون الناس وضع هذا الخيار في .yarnrc و لا داعي للقلق بشأن ذلك طوال الوقت

أعتقد أن هذه الميزة مهمة للغاية.

يمكنني التفكير في العديد من حالات الاستخدام ، خاصة عندما يتعلق الأمر بمؤلفي المكتبات.

لنفترض أنني أريد تطوير مكتبة مكون بها react و react-dom كـ peerDependencies (لا أريد أن يتم تجميعها في النهاية بواسطة أي شخص يستخدمها ، فسيؤدي ذلك إلى تكرار هاتين المكتبتين ويمكن أن تسبب مشاكل ، والتي عانيت منها من قبل).

أرغب في اختبار مكتبة المكونات الخاصة بي مع تثبيت تلك peerDependencies ، لذلك أود تشغيل yarn --include-peerDeps (أو شيء من هذا القبيل) على CI وعلى جهازي ، ولكن عندما يقوم شخص ما بتشغيل yarn على الحزمة الخاصة بهم أريدهم أن يستخدموا التبعيات الخاصة بهم react و react-dom لتشغيل اختباراتهم (لا يهم كيف يفعلون ذلك).

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

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

يسعدني مناقشة التنفيذ والمساعدة إذا لزم الأمر.

lucasfcosta لا يمكن أن توافق أكثر! ليس لدي الكثير من الوقت للعمل عليه هذه الأيام ، لذلك كنت أحاول أن أتجول عندما يمكنني ذلك ، لكن لا يبدو أنني أحصل على الخيار من خيار سطر الأوامر. أحب يد المساعدة رغم ذلك :)

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

أنا حاليًا أتبع نهج الازدواجية (devDependencies و peerDependencies) لكنني سأحب هذه الميزة بشدة حتى أستطيع التوقف عن فعل ذلك.

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

const pkg = require('./package.json');
const entries = Object.entries(pkg.peerDependencies);
const shell = require('shelljs');

let deps = ['yarn add'];
for ([dep, version] of entries) {
    deps[deps.length] = `${dep}@${version}`;
}

deps.push('--peer');
const cmd = deps.join(' ');
console.log('Installing peer deps!\n -----', cmd);
const result = shell.exec(cmd);

if (result.code !== 0) {
    shell.echo('Error: installing peer dependencies');
    shell.exit(1);
}

رائع! الآن يمكننا فقط لصقها في الغزل وإضافة علم أو أي شيء آخر.

يوم الخميس ، 4 أكتوبر 2018 ، الساعة 17:29 مساءً باسكوال مانجيالافوري إخطارات github.com
كتب:

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

"const pkg = تتطلب ('./ package.json') ؛
إدخالات const = Object.entries (pkg.peerDependencies) ؛
قذيفة const = تتطلب ('shelljs') ؛

اسمحوا deps = ['إضافة الغزل'] ؛
لـ ([dep، version] من الإدخالات) {
deps [deps.length] = $ {dep} @ $ {version}؛
}

deps.push ('- نظير') ؛
const cmd = deps.join ('') ؛
console.log ('Installing peer deps! n -----'، cmd) ؛
نتيجة const = shell.exec (cmd) ؛

إذا (result.code! == 0) {
shell.echo ("خطأ: تثبيت تبعيات الأقران") ؛
shell.exit (1) ؛
} `

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

أنا أيضًا أتبع نهج الازدواجية كما قال

راجع للشغل ، هل لدى أي شخص حل أفضل بحيث لا نحتاج إلى إضافة حزمة واحدة مرتين (devDependencies و peerDependencies)؟

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

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

قد يكون وضع علامة لتثبيت الحزم في كائن peerDependencies المحلي أمرًا رائعًا ، لكنني أيضًا لا أرى أي جانب سلبي يجعل التثبيت _only_ local peerDependencies السلوك الافتراضي. ومن المنطقي أنه من المنطقي أن تكون تبعيات الأقران موجودة حتى تعمل الحزمة في أي مكان آخر ، فلماذا تكون مختلفة محليًا؟

سيكون رأيي في استخدام العلم كما يلي بسبب محاذاته مع
yarn add --peer .

yarn --peer
# and
yarn install --peer

على الأقل يجب تقديم العلم.

أتساءل عما إذا كان استخدام تطبيق test منفصل يعد حلاً جيدًا هنا؟ يمكنك بعد ذلك إضافة كل ما تبذلونه من peerDependencies كـ dependencies test لتطبيق

• يبقي peerDependencies خارج devDependencies في مكتبتك
• ستختبر e2e مكتبتك ، بطريقة ما ... مع التأكد من أن التوزيع الخاص بك قد تم إنشاؤه بشكل صحيح ، وأنك تقوم بتصدير جميع مكوناتك بشكل صحيح وهذا النوع من الأشياء
• يتجنب الخطأ Invalid hook call العرضي عندما تنسى مسح node_modules من الحزمة الخاصة بك عند استخدام التبعيات المحلية ، مثل "my-package": "file:/path/to/my-package"

إذا كانت المزيد من المعلومات مفيدة للأشخاص ، فقد قمت بإنشاء ريبو تجريبي في محاولة لنمذجة هذا النهج وتوثيق المشكلة:
https://github.com/jamstooks/package-peer-dependencies

في الوقت الحالي ، يجب أن تكون قادرًا على تشغيل npx install-peerdeps <package> ثم يسألك CLI عما إذا كنت تريد استخدام Yarn للتثبيت ، إذا كان لديك قفل غزل وما إلى ذلك في المجلد. على الأقل هذا عمل معي الآن.

مزيد من المناقشة من Arcanis ("فشل التثبيت على أقسام النظراء المفقودة") وإيزاك ("تثبيت قسم النظراء تلقائيًا") هنا في NPM RFC:

https://github.com/npm/rfcs/pull/43

ساعدني منشور المدونة هذا في حل هذه المشكلة: https://dev.to/yvonnickfrin/how-to-handle-peer-dependencies-when-developing-modules-18fa

لدي مشكلة ذات صلة على ما أعتقد.
بالنسبة إلى الحد الأدنى من repro ، لدي قائمة التبعيات هذه:

  "dependencies": {
    "prismic-reactjs": "^1.2.0"
  },
  "peerDependencies": {
    "react": "^16.12.0"
  },
  "devDependencies": {
    "react": "^16.12.0",
    "redux": "^4.0.5"
  }

توضيح: تعتمد الحزمة الخاصة بي على وجود react في وقت التشغيل ويحتاجها أيضًا للاختبار. redux هنا لأغراض العرض ، انظر أدناه.

الآن ، يعتمد prismic-reactjs أيضًا على react كاعتماد على الأقران.
ماذا يحدث بعد استدعاء yarn --production ؟

تم تثبيت React على حدٍ سواء و __ تم رفعها_
أتوقع حدوث _لا شيء_ من الاثنين.

لأغراض العرض ، تمت إضافة redux هنا وهو _not_ مثبت والذي (على ما أظن) يثبت أن التبعية العابرة للأقران هي سبب المشكلة.

Repro repo: https://github.com/emirotin/yarn-react-repro . قم بتشغيل test.sh للفحص السريع.

لدى npm هذه الميزة الآن مع v7 ... أي سبب لعدم إضافة هذا إلى الغزل؟

sajadghawami على حد علمي ، لدى arcanis بعض التحفظات الكبيرة جدًا حول القيام بذلك:

https://github.com/npm/rfcs/pull/43#issuecomment -520584797