كيفية حذف node_modules على Mac دون فقدان مشروعك
فريق AskClean · آخر تحديث 2026-08-05
يمكنك حذف مجلد node_modules من مشروع إذا ظل package.json وملف القفل الصحيح وكل مصادر الاعتماديات متاحة. قس المشروع أولًا، وأوقف العمليات النشطة، وانقل المجلد المؤكد وحده إلى سلة المهملات. ثم أعد التثبيت بمدير الحزم نفسه، واختبر البناء والتشغيل قبل إفراغ السلة.
افصل node_modules عن المشروع وذاكرة npm المؤقتة
يمثل node_modules شجرة الاعتماديات المثبتة للمشروع؛ يمكن إعادة بنائه في الظروف المناسبة، لكن المشروع لن يعمل أو يُبنى حتى يكتمل التثبيت. أما package.json وملفات القفل والشيفرة المصدرية والإعدادات والتصحيحات وملفات مساحات العمل وسجل Git فهي وصفة إعادة البناء ولا يجوز حذفها. وذاكرة تنزيلات npm المشتركة، الموجودة افتراضيًا في ~/.npm، فئة مستقلة كذلك.
تأكد من إمكان استعادة الاعتماديات فعلًا
يجعل ملف القفل حل الاعتماديات متوقعًا، لكنه لا يحفظ الحزم نفسها. تحقق من مدير الحزم وإصداره، ومن الوصول إلى السجلات الخاصة وVPN واعتماديات Git وfile: وحزم مساحات العمل المحلية والتنزيلات الخارجية وأدوات بناء الوحدات الأصلية. لم يعد npm v12 يقرأ npm-shrinkwrap.json؛ فإذا كان هو ملف القفل الوحيد في مشروع قديم، فأعد تسمية هذا الملف ذي التنسيق نفسه إلى package-lock.json قبل استخدام npm v12. لا تستبدل أبدًا package-lock.json موجودًا؛ قارن الملفين ووفّق بينهما على حدة. وأي تعديل موجود داخل node_modules وحده سيضيع.
- من جذر المشروع شغل pwd وdu -sh ./node_modules، وسجل أيضًا المساحة الحرة على macOS.
- تحقق من package.json وملف القفل الصحيح وإعدادات مساحات العمل والتغييرات المحلية؛ ومع npm v12 لا تغيّر اسم npm-shrinkwrap.json إلى package-lock.json إلا إذا لم يكن package-lock.json موجودًا أصلًا.
- تأكد من الوصول إلى السجلات الخاصة واعتماديات Git وfile: والحزم المحلية والتنزيلات الخارجية وأدوات البناء، ثم أوقف العمليات التي تستخدم node_modules.
- انقل مجلد node_modules المؤكد وحده إلى سلة المهملات، وأعد التثبيت من الجذر الصحيح بمدير الحزم وملف القفل اللذين يعتمدهما المستودع.
- شغل البناء والاختبارات وlint والتطبيق، وقس المساحة مجددًا، ثم أفرغ سلة المهملات فقط بعد نجاح التحقق.
لا تجعل node_modules النسخة الوحيدة من حزمة أو إصلاح يدوي. إذا تعذر جلب إحدى الاعتماديات بإصدارها الدقيق ولم تحفظ مصدرها في موضع آخر، فقد يجعل الحذف مشروعًا قديمًا غير قابل للاستعادة.
أزل مجلد اعتماديات واحدًا بعد التحقق
من جذر المشروع المؤكد، انقل node_modules وحده إلى سلة المهملات في Finder، لا المستودع الأب. يتجاوز rm -rf ./node_modules سلة المهملات ولا يمكن التراجع عنه، لذا تحقق أولًا من الجذر باستخدام pwd. بعد ذلك استخدم npm ci عندما يكون package-lock.json هو المرجع، أو الخيار الذي يمنع تغيير ملف القفل والمعتمد في المستودع عند استخدام pnpm أو Yarn أو Bun. وفي المستودع الموحد (monorepo) ابدأ من ملف القفل الجذري وتعامل مع مساحات العمل كنظام اعتماديات واحد.
أعد التثبيت ثم تحقق من المشروع كله
نجاح التثبيت لا يثبت وحده أن المشروع استُعيد. شغل أوامر البناء والاختبارات وlint والتشغيل الموثقة؛ فقد تفشل الوحدات الأصلية أو نصوص دورة الحياة بعد تغير الأدوات. تشمل كلفة الاستعادة التنزيل وفك الضغط وإنشاء الروابط وربما الترجمة. عند الفشل، استعد المجلد من سلة المهملات إن أمكن، وشخص الوصول والشبكة والإصدارات وملف القفل قبل تنظيف مشروع آخر.
حدود الحذف وكلفة الاستعادة
اعثر على مجلدات node_modules الكبيرة، واحم الشيفرة المصدرية وملف القفل، ثم أعد تثبيت الاعتماديات بأمان باستخدام npm أو pnpm أو Yarn أو Bun.
| العنصر أو الإجراء | موضع أو أداة الفحص | العاقبة |
|---|---|---|
| افصل node_modules عن المشروع وذاكرة npm المؤقتة | مجلد المشروع / node_modules | يمثل node_modules شجرة الاعتماديات المثبتة للمشروع؛ يمكن إعادة بنائه في الظروف المناسبة، لكن المشروع لن يعمل أو يُبنى حتى يكتمل التثبيت. أما package.json وملفات القفل والشيفرة المصدرية والإعدادات والتصحيحات وملفات مساحات العمل وسجل Git فهي وصفة إعادة البناء ولا يجوز حذفها. وذاكرة تنزيلات npm المشتركة، الموجودة افتراضيًا في ~/.npm، فئة مستقلة كذلك. |
| تأكد من إمكان استعادة الاعتماديات فعلًا | package.json + ملف القفل + إعدادات مساحات العمل | يجعل ملف القفل حل الاعتماديات متوقعًا، لكنه لا يحفظ الحزم نفسها. تحقق من مدير الحزم وإصداره، ومن الوصول إلى السجلات الخاصة وVPN واعتماديات Git وfile: وحزم مساحات العمل المحلية والتنزيلات الخارجية وأدوات بناء الوحدات الأصلية. لم يعد npm v12 يقرأ npm-shrinkwrap.json؛ فإذا كان هو ملف القفل الوحيد في مشروع قديم، فأعد تسمية هذا الملف ذي التنسيق نفسه إلى package-lock.json قبل استخدام npm v12. لا تستبدل أبدًا package-lock.json موجودًا؛ قارن الملفين ووفّق بينهما على حدة. وأي تعديل موجود داخل node_modules وحده سيضيع. |
| أزل مجلد اعتماديات واحدًا بعد التحقق | سلة المهملات / إعادة التثبيت بمدير الحزم | من جذر المشروع المؤكد، انقل node_modules وحده إلى سلة المهملات في Finder، لا المستودع الأب. يتجاوز rm -rf ./node_modules سلة المهملات ولا يمكن التراجع عنه، لذا تحقق أولًا من الجذر باستخدام pwd. بعد ذلك استخدم npm ci عندما يكون package-lock.json هو المرجع، أو الخيار الذي يمنع تغيير ملف القفل والمعتمد في المستودع عند استخدام pnpm أو Yarn أو Bun. وفي المستودع الموحد (monorepo) ابدأ من ملف القفل الجذري وتعامل مع مساحات العمل كنظام اعتماديات واحد. |
| أعد التثبيت ثم تحقق من المشروع كله | البناء + الاختبارات + تشغيل التطبيق | نجاح التثبيت لا يثبت وحده أن المشروع استُعيد. شغل أوامر البناء والاختبارات وlint والتشغيل الموثقة؛ فقد تفشل الوحدات الأصلية أو نصوص دورة الحياة بعد تغير الأدوات. تشمل كلفة الاستعادة التنزيل وفك الضغط وإنشاء الروابط وربما الترجمة. عند الفشل، استعد المجلد من سلة المهملات إن أمكن، وشخص الوصول والشبكة والإصدارات وملف القفل قبل تنظيف مشروع آخر. |
الأسئلة الشائعة
هل حذف node_modules آمن على Mac؟
يكون آمنًا غالبًا إذا بقي package.json وملف القفل الصحيح وملفات مساحات العمل والشيفرة المصدرية وجميع مصادر الاعتماديات سليمة. لكن المشروع سيظل غير قابل للعمل أو البناء حتى يكتمل التثبيت والتحقق.
هل أحذف package-lock.json مع node_modules؟
لا. يحتاج npm إلى package-lock.json لإعادة إنتاج حل الاعتماديات. لم يعد npm v12 يقرأ npm-shrinkwrap.json؛ فإذا كان هو ملف القفل الوحيد في مشروع قديم، فأعد تسميته package-lock.json بدلًا من حذفه، ولا تستبدل أبدًا ملف package-lock.json موجودًا.
هل node_modules هو نفسه ذاكرة npm المؤقتة؟
لا. يحتوي node_modules اعتماديات مشروع مثبتة، بينما تحفظ ذاكرة npm المشتركة تنزيلات قابلة لإعادة الاستخدام وتوجد افتراضيًا في ~/.npm. حذف أحدهما لا يحذف الآخر، ولكل منهما نطاق وكلفة استعادة مختلفان.
المصادر