npm-кэш и node_modules занимают место на Mac? Что делать безопасно

Если npm-кэш и старые папки node_modules занимают место на вашем Mac, сначала разделите общий npm-кэш и локальные зависимости проектов. Изучите кэш перед очисткой и удаляйте устаревшие node_modules, только когда готовы переустановить зависимости или проект вам больше не нужен.

Это различие важно, потому что npm cache и node_modules решают разные задачи. И последствия их очистки тоже разные.

Один — повторно используемый кэш пакетов. Другой — дерево зависимостей, через которое проект фактически работает. Обращаться с ними как с однородным мусором — самый быстрый способ освободить место, а потом потерять время на восстановление окружения.

Краткий ответ

Почему npm-кэш и node_modules так быстро разрастаются на Mac

Машины JavaScript-разработчиков редко заполняются от одного проекта. Настоящая причина — накопление.

Вы ставите пакеты в разных приложениях, ветках, прототипах и клиентских репозиториях. npm хранит общий кэш, чтобы не загружать всё заново при каждой установке. Каждый проект также держит собственное дерево зависимостей в node_modules.

В итоге диск растёт сразу с двух сторон:

• общий npm-кэш, который расширяется по мере установки новых пакетов и версий;
• множество папок проектов, каждая со своим деревом node_modules;
• дублирующиеся или почти дублирующиеся зависимости в старых репозиториях;
• нативные модули и пакеты инструментальной цепочки, добавляющие стоимость пересборки, даже если технически они одноразовые;
• устаревшие проекты, которые никогда не были заархивированы, удалены или переустановлены чисто.

Результат знаком многим: один репозиторий — это неудобство, десять — дорого, а год обычной работы превращается в незаметную проблему с хранилищем.

npm-кэш и node_modules: в чём разница?

Это самое важное различие.

Согласно официальной документации npm, файлы кэша по умолчанию хранятся в ~/.npm на POSIX-системах, а локальные установки помещаются в ./node_modules внутри корня текущего пакета. npm сначала загружает пакеты в кэш, а затем распаковывает их в node_modules для нужного проекта.

Поэтому фраза «npm занимает место» обычно слишком расплывчата. Нужно понимать, исходит ли давление от общего кэша, от старых установок проектов или от обоих сразу.

Что следует из документации npm

npm-кэш задуман именно как кэш, а не как рабочее дерево зависимостей проекта. npm прямо указывает, что кэш можно восстановить позже.

node_modules — другое дело. В этой папке хранятся пакеты проекта, исполняемые файлы и локальный граф зависимостей. Если вы удалите её, вы не просто очищаете кэш — вы убираете зависимости, через которые проект сейчас работает.

Безопасно ли удалять npm-кэш на Mac?

Как правило, да, но важна причина.

В официальной документации npm сказано, что кэш проверяется на целостность и его очистка обычно нужна только для освобождения дискового пространства. Это важное уточнение: npm-кэш не нужно считать ценными данными, но и без причины стирать его тоже не стоит.

Безопасная модель такая:

• если на Mac мало места, очистка кэша — разумный компромисс;
• если установки работают нормально, очищать кэш обычно нет нужды;
• если вы его очистите, ожидайте, что последующие установки будут загружать пакеты заново;
• если вы хотите сначала проверить состояние кэша, используйте npm cache verify.

Лучший первый шаг: проверьте, а потом очищайте

npm документирует npm cache verify как шаг офлайн-проверки содержимого кэша. Это лучший первый вариант, когда нужен малорисковый анализ перед освобождением места.

npm cache verify

Если ваша цель — именно освободить место, документированная команда очистки npm:

npm cache clean --force

Флаг --force обязателен по замыслу. npm рассматривает очистку кэша как осознанное решение о дисковом пространстве, а не как рутинное обслуживание.

Безопасно ли удалять node_modules на Mac?

Иногда да, но здесь контекст гораздо важнее.

Удаление node_modules убирает локальное дерево зависимостей проекта. Если проект активен, последствия обычно очевидны: скрипты перестают находить пакеты, локальные бинарники исчезают из node_modules/.bin, а следующая установка или сборка может занять больше времени, чем хотелось бы.

Это не значит, что удалять никогда не стоит. Это значит, что делать это нужно осознанно.

Хорошие кандидаты для удаления node_modules:

• старый проект, который вы больше не запускаете;
• устаревшая демка или прототип, который можно пересобрать позже;
• репозиторий, который вы собираетесь чисто переустановить;
• проект с надёжным lockfile, где переустановка ожидаема и приемлема.

Ситуации с более высокими затратами:

• активный рабочий репозиторий прямо перед дедлайном, демо или релизной сборкой;
• проект с нативными модулями, которые долго пересобирать;
• рабочее пространство, к которому вы не прикасались месяцами и можете не вспомнить, как его восстановить;
• репозиторий без чёткой истории зависимостей или без ожидаемого lockfile.

Почему старые node_modules так вредны

Один проект ещё терпим. Настоящая потеря — когда их много.

Каждый старый репозиторий может хранить полное дерево зависимостей, метаданные пакетного менеджера, опциональные нативные пакеты, инструментальные цепочки фреймворков и артефакты конкретных версий. Именно поэтому разработчики часто думают, что проблема в npm, хотя главный виновник — куча забытых node_modules в retirированных проектах.

Как очистить npm-кэш вручную

Если вы предпочитаете ручной путь, будьте точны и осмотрительны.

1. Проверьте активный каталог кэша

Если вы когда-то меняли настройки npm, кэш может быть не в стандартном расположении. Спросите npm:

npm config get cache

2. Проверьте кэш перед удалением

Сначала используйте документированный шаг проверки:

npm cache verify

3. Очищайте кэш, только если действительно хотите вернуть место

Если освобождение дискового пространства важнее последующих повторных загрузок:

npm cache clean --force

4. При необходимости перепроверьте размер

Когда путь к кэшу известен, можно оценить его размер напрямую:

du -sh "$(npm config get cache)"

Это более безопасная последовательность, потому что она разделяет проверку расположения, верификацию и очистку на отдельные решения.

Как найти старые папки node_modules перед удалением

Обычно это более ценный этап очистки.

Начните с проектов, которые вы больше активно не собираете. Это важнее, чем искать одну самую большую папку в Finder без контекста.

Используйте такой порядок:

1. Найдите папки node_modules в основном каталоге проектов.
2. Проверьте, какие репозитории устарели, заархивированы или легко переустанавливаются.
3. Уточните, нужен ли проект для локальной работы на этой неделе.
4. Удаляйте только те node_modules, стоимость восстановления которых вы понимаете.

Если хотите использовать Терминал для анализа, выполните команды, которые покажут, где эти папки находятся, до того как что-то удалять:

find ~/Projects -type d -name node_modules -prune -print
find ~/Projects -type d -name node_modules -prune -exec du -sh {} +

Это всё ещё ручной подход, но он лучше, чем эмоциональная реакция на одну огромную рабочую папку.

Что стоит проверить перед удалением node_modules проекта

• Репозиторий ещё активен?
• У вас есть ожидаемый lockfile?
• Есть ли нативные модули или шаги кодогенерации, замедляющие переустановку?
• Является ли проект частью монорепозитория или workspace, который не стоит беспокоить второпях?
• Будет ли архивирование или удаление всего старого проекта лучшим решением, чем только удаление node_modules?

Часто самое эффективное действие — не «стереть зависимости везде», а «удалить старый проект, который вам больше не нужен».

А как насчёт кэшей yarn, pnpm и bun?

Эту часть нужно рассматривать отдельно от npm.

Если проект использует другой пакетный менеджер, применяйте его собственную модель очистки, а не предполагайте, что команды npm подойдут напрямую.

Yarn

Современный Yarn документирует yarn cache clean как команду для удаления общих файлов кэша. Также доступны флаги --mirror и --all для более широкой очистки.

yarn cache clean

pnpm

pnpm использует модель хранилища вместо точного кэша как у npm. В официальной документации pnpm pnpm store prune описан как удаление неиспользуемых пакетов из хранилища, при этом отмечается, что последующие установки могут заново загрузить удалённые пакеты.

pnpm store prune

Bun

Bun документирует глобальный кэш пакетов в ~/.bun/install/cache по умолчанию. Также отмечается, что пакеты после загрузки копируются в node_modules, поэтому Bun может создать ту же путаницу «кэш плюс установка проекта», если смотреть только на размер папки.

Важнее не запоминать каждую команду, а не смешивать модели хранения. npm-кэш, кэш Yarn, хранилище pnpm и кэш Bun — это родственные, но не идентичные проблемы.

Почему очистка безопаснее при анализе по экосистемам

node_modules — редко единственная проблема хранилища разработчика на Mac. Обычно рядом находятся данные Xcode, хранилище симуляторов, образы Docker, кэш сборки, логи и другие специфичные пути.

Обычный файловый браузер покажет, что папка большая. Но не скажет, является ли она:

• пересоздаваемым npm-кэшем;
• деревом зависимостей активного рабочего пространства;
• хранилищем pnpm;
• кэшем Docker;
• или другой экосистемой, которая просто оказалась рядом с вашими проектами.

Поэтому очистка хранилища разработчика работает лучше, когда процесс учитывает экосистемы.

Если ваша реальная ситуация — «npm плюс Docker плюс старые данные Xcode плюс слишком много забытых репозиториев», то более широкая модель с предварительной проверкой полезнее, чем погоня за одной папкой за раз.

Итог

Если npm-кэш и node_modules занимают место на вашем Mac, не относитесь к ним как к одной и той же цели очистки.

Используйте npm cache verify, а когда освобождение места — реальная цель, npm cache clean --force для общего кэша. Проверяйте старые node_modules проект за проектом и удаляйте их, только когда понимаете стоимость переустановки.

Это более безопасный путь: разделяйте кэш и состояние рабочего пространства, проверяйте устаревшие проекты раньше активных и привязывайте очистку разработчика к контексту экосистем, а не к слепому удалению папок.