Як видалити node_modules на Mac і не втратити проєкт
Команда AskClean · Оновлено 2026-08-05
Папку node_modules можна видалити, якщо збережено package.json, належний lock-файл, вихідний код і конфігурацію, а всі залежності досі доступні. Спершу виміряйте один проєкт і зупиніть процеси, що використовують його залежності. Потім перемістіть у Смітник лише node_modules, відновіть залежності прийнятим у репозиторії менеджером пакетів і перевірте збірку, тести та запуск, перш ніж спорожняти Смітник.

Відокремте node_modules від проєкту й кешу npm
node_modules — це встановлене дерево залежностей проєкту: за належних умов його можна відтворити, але до повторного встановлення проєкт не запускатиметься й не збиратиметься. package.json, lock-файл, вихідний код, конфігурація, патчі, файли робочих областей та історія Git потрібні для відновлення, тому їх видаляти не можна. Спільний кеш завантажень npm, зазвичай у ~/.npm, є окремою категорією і впливає на кілька проєктів.
Переконайтеся, що залежності справді можна відновити
Lock-файл робить розв’язання залежностей передбачуваним, але не зберігає самих пакетів. Перевірте менеджер пакетів і його версію, доступ до приватних реєстрів, VPN, залежностей Git і file:, локальних робочих областей, зовнішніх завантажень та інструментів для збирання нативних модулів. npm v12 більше не читає npm-shrinkwrap.json: якщо це єдиний lock-файл старого проєкту, перейменуйте його на package-lock.json. Ніколи не перезаписуйте наявний package-lock.json; якщо в проєкті є обидва файли, порівняйте й узгодьте їх окремою контрольованою зміною. Правки, що існують лише в node_modules, після видалення зникнуть.
- У корені проєкту виконайте pwd і du -sh ./node_modules, а потім запишіть обсяг вільного місця в macOS.
- Перевірте package.json, належний lock-файл, конфігурацію робочих областей і локальні зміни; для npm v12 перейменуйте npm-shrinkwrap.json на package-lock.json лише тоді, коли package-lock.json ще не існує.
- Переконайтеся, що доступні приватні реєстри, залежності Git і file:, локальні пакети, зовнішні завантаження та інструменти збирання, а тоді зупиніть процеси, що використовують node_modules.
- Перемістіть у Смітник лише перевірену папку node_modules і встановіть залежності знову з належного кореня, використовуючи прийняті в репозиторії менеджер пакетів і lock-файл.
- Запустіть збірку, тести, лінтер і застосунок, знову перевірте вільне місце та спорожняйте Смітник лише після успішної перевірки.
Не використовуйте node_modules як єдину копію пакета чи ручної правки. Якщо точна залежність більше недоступна й ніде не збережена, видалення може зробити старий проєкт непрацездатним.
Видаліть лише одну перевірену папку залежностей
Із перевіреного кореня проєкту перемістіть через Finder у Смітник тільки node_modules, а не весь репозиторій. Команда rm -rf ./node_modules оминає Смітник і видаляє безповоротно, тому спершу перевірте корінь командою pwd. Якщо основним lock-файлом є package-lock.json, використовуйте npm ci; для pnpm, Yarn або Bun застосовуйте зафіксований у репозиторії менеджер і режим, що забороняє зміну lock-файла. У монорепозиторії починайте з кореневого lock-файла й розглядайте всі робочі області як одну систему залежностей.
Перевстановіть залежності й перевірте весь проєкт
Успішне встановлення ще не доводить, що проєкт відновлено. Запустіть передбачені репозиторієм збірку, тести, лінтер і застосунок: нативні модулі та скрипти життєвого циклу можуть зламатися після зміни Node.js, macOS або інструментів. Відновлення потребує завантажити й розпакувати пакети, створити посилання, запустити скрипти, а іноді й скомпілювати код. У разі помилки поверніть папку зі Смітника та перевірте доступ, мережу, версії й lock-файл, перш ніж очищати наступний проєкт.
Що можна видаляти та скільки коштує відновлення
Знайдіть великі папки node_modules, збережіть вихідний код і lock-файл, а потім безпечно встановіть залежності знову через npm, pnpm, Yarn або Bun.
| Об’єкт або дія | Де перевірити | Наслідки видалення |
|---|---|---|
| Відокремте node_modules від проєкту й кешу npm | <проєкт>/node_modules | node_modules — це встановлене дерево залежностей проєкту: за належних умов його можна відтворити, але до повторного встановлення проєкт не запускатиметься й не збиратиметься. package.json, lock-файл, вихідний код, конфігурація, патчі, файли робочих областей та історія Git потрібні для відновлення, тому їх видаляти не можна. Спільний кеш завантажень npm, зазвичай у ~/.npm, є окремою категорією і впливає на кілька проєктів. |
| Переконайтеся, що залежності справді можна відновити | package.json + lock-файл + конфігурація робочих областей | Lock-файл робить розв’язання залежностей передбачуваним, але не зберігає самих пакетів. Перевірте менеджер пакетів і його версію, доступ до приватних реєстрів, VPN, залежностей Git і file:, локальних робочих областей, зовнішніх завантажень та інструментів для збирання нативних модулів. npm v12 більше не читає npm-shrinkwrap.json: якщо це єдиний lock-файл старого проєкту, перейменуйте його на package-lock.json. Ніколи не перезаписуйте наявний package-lock.json; якщо в проєкті є обидва файли, порівняйте й узгодьте їх окремою контрольованою зміною. Правки, що існують лише в node_modules, після видалення зникнуть. |
| Видаліть лише одну перевірену папку залежностей | Смітник / повторне встановлення через менеджер пакетів | Із перевіреного кореня проєкту перемістіть через Finder у Смітник тільки node_modules, а не весь репозиторій. Команда rm -rf ./node_modules оминає Смітник і видаляє безповоротно, тому спершу перевірте корінь командою pwd. Якщо основним lock-файлом є package-lock.json, використовуйте npm ci; для pnpm, Yarn або Bun застосовуйте зафіксований у репозиторії менеджер і режим, що забороняє зміну lock-файла. У монорепозиторії починайте з кореневого lock-файла й розглядайте всі робочі області як одну систему залежностей. |
| Перевстановіть залежності й перевірте весь проєкт | збірка + тести + запуск застосунку | Успішне встановлення ще не доводить, що проєкт відновлено. Запустіть передбачені репозиторієм збірку, тести, лінтер і застосунок: нативні модулі та скрипти життєвого циклу можуть зламатися після зміни Node.js, macOS або інструментів. Відновлення потребує завантажити й розпакувати пакети, створити посилання, запустити скрипти, а іноді й скомпілювати код. У разі помилки поверніть папку зі Смітника та перевірте доступ, мережу, версії й lock-файл, перш ніж очищати наступний проєкт. |
FAQ
Чи безпечно видаляти node_modules на Mac?
Зазвичай так, якщо збережено package.json, належний lock-файл, файли робочих областей, вихідний код і всі джерела залежностей. Але до повторного встановлення та перевірки проєкт не запускатиметься й не збиратиметься.
Чи треба видаляти package-lock.json разом із node_modules?
Ні. package-lock.json потрібен npm для відтворюваного розв’язання. npm v12 більше не читає npm-shrinkwrap.json: якщо це єдиний lock-файл старого проєкту, перейменуйте його на package-lock.json, але ніколи не перезаписуйте файл, який уже має цю назву.
node_modules і кеш npm — це те саме?
Ні. node_modules містить установлені залежності одного проєкту, а спільний кеш npm зазвичай розташований у ~/.npm. Видалення одного не видаляє інше, а вартість відновлення стосується різної кількості проєктів.
Джерела