كيفية مسح ذاكرة npm المؤقتة على Mac بأمان
فريق AskClean · آخر تحديث 2026-08-05
اعثر على الذاكرة النشطة باستخدام npm config get cache، وقس مسارها باستخدام du، ثم شغل npm cache verify قبل أي حذف. لا تستخدم npm cache clean --force إلا عند الحاجة الفعلية إلى المساحة وقبول التنزيلات التالية. لا يحذف ذلك node_modules ولا package.json ولا ملف القفل.
افصل ذاكرة npm المؤقتة عن ملفات المشروع واعتمادياته
تحتفظ ذاكرة npm بتنزيلات قابلة لإعادة الاستخدام بين عدة مشاريع. موقعها الافتراضي على macOS هو ~/.npm، لكن الإعدادات قد تنقلها. أما node_modules فهو شجرة اعتماديات مثبتة لمشروع، وpackage.json وpackage-lock.json يصفان حالته وليسا ذاكرة مؤقتة. كذلك ليس npm-shrinkwrap.json ذاكرة مؤقتة، ولم يعد npm v12 يقرأه؛ فإذا كان هو ملف القفل الوحيد في مشروع قديم، فأعد تسمية هذا الملف ذي التنسيق نفسه إلى package-lock.json قبل إعادة التثبيت باستخدام npm v12، ولا تستبدل package-lock.json موجودًا.
قس الذاكرة النشطة وابدأ بالتحقق منها
لا تفترض أن وجود ~/.npm يعني أنه المسار النشط. يعرض npm config get cache المسار المستخدم ضمن الإعداد الحالي؛ قس ذلك المسار نفسه وسجل المساحة الحرة. يفحص npm cache verify الفهرس وسلامة المحتوى ويحذف البيانات غير اللازمة دون إهدار كل التنزيلات الصالحة، وغالبًا يكفي للصيانة. أما ERESOLVE أو المصادقة أو 404 أو إعداد الوكيل الشبكي أو توافق Node.js أو بناء الوحدات الأصلية أو postinstall فتحتاج إلى تشخيص آخر.
- شغل npm --version وnpm config get cache، ثم تأكد من أن المسار الظاهر لذاكرة مؤقتة لا لمسار مشروع.
- قس المسار الدقيق باستخدام du -sh وسجل المساحة الحرة في macOS دون تغيير package.json أو ملف القفل.
- أوقف أي npm install أو npm ci أو npm exec أو نشر جار، ثم شغل npm cache verify واحتفظ بملخصه وأخطائه.
- شغل npm cache clean --force فقط إذا لم يكن التحقق كافيًا، وكانت المساحة مهمة، وظلت الملفات المطلوبة قابلة للوصول.
- شغل npm cache verify مرة أخرى، وقس المسار نفسه، ثم تحقق من مشروع ممثل بملف قفله دون تغيير وبنائه واختباراته.
لا تمرر أبدًا مسارًا غير متحقق منه إلى rm -rf. ولا تجمع مسح الذاكرة المؤقتة مع حذف ملف القفل أو إعادة إنشائه؛ فتغيير سببين معًا يبدد المقارنة اللازمة لتشخيص المشكلة.
استخدم npm cache clean --force عند وجود مبرر فقط
شغل npm cache clean --force فقط إذا كانت الذاكرة المقاسة كبيرة بما يكفي، وكانت المساحة مطلوبة الآن، ويمكن استعادة الملفات اللازمة. قد يكون التثبيت التالي أو npm ci أبطأ، وقد يفشل دون اتصال أو عند تعذر سجل خاص أو مضيف Git أو وكيل شبكي أو حزمة سحبت من المصدر. اقصر --force على هذا الأمر ولا تحفظه إعدادًا دائمًا في npm لأنه يخفف حمايات عمليات أخرى أيضًا.
تحقق من النتيجة دون تغيير شجرة الاعتماديات
بعد المسح، اطلب المسار مجددًا باستخدام npm config get cache، وقسه وقارن المساحة الحرة الفعلية في macOS. اختبر مشروعًا ممثلًا مع package.json وملف القفل دون تغيير، ثم شغل بناءه واختباراته. إذا عاد الخطأ نفسه، فلا تكرر المسح؛ راجع الرسالة المحفوظة وإصداري npm وNode.js وبيانات الدخول والشبكة. يتعرف AskClean على ~/.npm الافتراضي، أما المسار المخصص فيبقى بحاجة إلى تحقق عبر npm.
حدود الحذف وكلفة الاستعادة
اعثر على ذاكرة التنزيل التي يستخدمها npm فعلًا وقسها وتحقق منها أولًا، ولا تمسحها إلا إذا بررت المساحة كلفة التنزيل اللاحقة.
| العنصر أو الإجراء | موضع أو أداة الفحص | العاقبة |
|---|---|---|
| افصل ذاكرة npm المؤقتة عن ملفات المشروع واعتمادياته | npm config get cache | تحتفظ ذاكرة npm بتنزيلات قابلة لإعادة الاستخدام بين عدة مشاريع. موقعها الافتراضي على macOS هو ~/.npm، لكن الإعدادات قد تنقلها. أما node_modules فهو شجرة اعتماديات مثبتة لمشروع، وpackage.json وpackage-lock.json يصفان حالته وليسا ذاكرة مؤقتة. كذلك ليس npm-shrinkwrap.json ذاكرة مؤقتة، ولم يعد npm v12 يقرأه؛ فإذا كان هو ملف القفل الوحيد في مشروع قديم، فأعد تسمية هذا الملف ذي التنسيق نفسه إلى package-lock.json قبل إعادة التثبيت باستخدام npm v12، ولا تستبدل package-lock.json موجودًا. |
| قس الذاكرة النشطة وابدأ بالتحقق منها | npm cache verify | لا تفترض أن وجود ~/.npm يعني أنه المسار النشط. يعرض npm config get cache المسار المستخدم ضمن الإعداد الحالي؛ قس ذلك المسار نفسه وسجل المساحة الحرة. يفحص npm cache verify الفهرس وسلامة المحتوى ويحذف البيانات غير اللازمة دون إهدار كل التنزيلات الصالحة، وغالبًا يكفي للصيانة. أما ERESOLVE أو المصادقة أو 404 أو إعداد الوكيل الشبكي أو توافق Node.js أو بناء الوحدات الأصلية أو postinstall فتحتاج إلى تشخيص آخر. |
| استخدم npm cache clean --force عند وجود مبرر فقط | npm cache clean --force | شغل npm cache clean --force فقط إذا كانت الذاكرة المقاسة كبيرة بما يكفي، وكانت المساحة مطلوبة الآن، ويمكن استعادة الملفات اللازمة. قد يكون التثبيت التالي أو npm ci أبطأ، وقد يفشل دون اتصال أو عند تعذر سجل خاص أو مضيف Git أو وكيل شبكي أو حزمة سحبت من المصدر. اقصر --force على هذا الأمر ولا تحفظه إعدادًا دائمًا في npm لأنه يخفف حمايات عمليات أخرى أيضًا. |
| تحقق من النتيجة دون تغيير شجرة الاعتماديات | التثبيت + اختبار العمل دون اتصال / السجل الخاص | بعد المسح، اطلب المسار مجددًا باستخدام npm config get cache، وقسه وقارن المساحة الحرة الفعلية في macOS. اختبر مشروعًا ممثلًا مع package.json وملف القفل دون تغيير، ثم شغل بناءه واختباراته. إذا عاد الخطأ نفسه، فلا تكرر المسح؛ راجع الرسالة المحفوظة وإصداري npm وNode.js وبيانات الدخول والشبكة. يتعرف AskClean على ~/.npm الافتراضي، أما المسار المخصص فيبقى بحاجة إلى تحقق عبر npm. |
الأسئلة الشائعة
هل npm cache clean --force آمن على Mac؟
لا يحذف شيفرة المشروع عندما يشير npm إلى ذاكرته الفعلية، لكنه يتخلص من تنزيلات قابلة لإعادة الاستخدام. قس وتحقق أولًا، وأوقف عمليات npm، وتوقع حاجة عمليات التثبيت اللاحقة إلى الشبكة.
هل أبدأ بـ npm cache verify أم npm cache clean؟
ابدأ دائمًا بـ npm cache verify؛ فهو يفحص السلامة ويحذف البيانات غير اللازمة مع إبقاء المحتوى الصالح. استخدم clean --force فقط لمساحة مقاسة أو مشكلة مؤكدة خاصة بالذاكرة لم يحلها verify.
هل مسح ذاكرة npm يحذف package-lock.json؟
لا. package.json وpackage-lock.json ملفا مشروع. لم يعد npm v12 يقرأ npm-shrinkwrap.json؛ فإذا كان هو ملف القفل الوحيد في مشروع قديم، فأعد تسميته package-lock.json دون استبدال ملف موجود، مع إبقاء حل الاعتماديات دون تغيير أثناء التنظيف.
المصادر