الحقل هو العقد
{ "packageManager": "pnpm@10.15.0"}الاسم، وبعديه @، وبعديها نسخة semver ثابتة. مفيش ^ ولا ~. Corepack بيرفض مدى في الحقل ده، لأن المدى مش عقد: النهاردة يحل لرقم وبكرة لرقم تاني.
القيم المسموحة للاسم: pnpm و yarn و npm.
corepack use غالبًا بيلحق الرقم ببصمة integrity، والشكل الناتج قريب من:
{ "packageManager": "pnpm@10.15.0+sha512.<hash>"}الجزء الأخير هاش طويل. متختصرهوش في الملف الحقيقي ومتكتبهوش بإيدك. Corepack يولّده ويقارن به الملف اللي نزّله. خليه يختار نوع البصمة؛ متربطش إعدادك بمثال مقال قديم.
أمر واحد يكتب ويحمّل
من جوه فولدر المشروع:
mkdir koshary && cd kosharynpm init -ycorepack use pnpm@10corepack use pnpm@10 يحل المدى مرة، ويكتب آخر إصدار مطابق كرقم ثابت مع البصمة، وبعدين يشغّل تثبيت. corepack use pnpm@10.15.0 يطلب الرقم ده بالظبط. corepack use pnpm@latest يقفز لآخر إصدار، وده قرار upgrade متعمد.
افتح package.json بعد الأمر. لو فوقيك فولدر فيه package.json وقفل زي pnpm-lock.yaml، Corepack ممكن يعتبرك جوه المشروع الأعلى ويكتب الحقل هناك. رسالة الرفض بتقول مسار الملف. اقرأ المسار قبل ما تدور في الفولدر اللي واقف فيه.
بعدها:
pnpm --versionالرقم اللي يطلع هو اللي في الحقل لو أمر pnpm معدّي على Corepack shim. راجع command -v pnpm لو ظهر رقم تاني.
ارفع جوه نفس الخط، ومتقفزش كبير
corepack upup يحدّث لآخر إصدار في نفس الخط الكبير، أو في المدى المكتوب في devEngines لو موجود. مش هيقفز من ١٠ لـ ١١. القفزة الكبيرة: corepack use pnpm@latest أو corepack use pnpm@11.
corepack install من غير -g يحمّل المدير المكتوب في المشروع ويجهّزه، من غير ما يغيّر الحقل. دي خطوة warm-up مفيدة، مش شرط قبل كل install؛ أول pnpm عبر Corepack يقدر يحمّل النسخة. العلم -g يغيّر الافتراضي بره المشاريع، مش اتفاق الفريق.
مدى في الحقل التاني، مش هنا
devEngines.packageManager يقدر يحمل مدى، زي >=10. Corepack يسأل الريجستري عن آخر نسخة جوه المدى، والنتيجة ممكن تتغير. عشان كده المدى لوحده مش تثبيت. التثبيت هو packageManager بنسخة كاملة. الفصل الجاي يجمع الاتنين من غير ما يتخانقوا.