Половина зависимостей в вашем проекте — забытый груз

Возьмите package.json или requirements.txt проекта старше двух лет и попробуйте честно, для каждой зависимости, ответить: зачем она здесь и используется ли до сих пор. В большинстве команд, где я это проверял, минимум треть библиотек не может объяснить никто из присутствующих.

Зависимости добавляются легко и почти никогда не удаляются. Кто-то подключил библиотеку под одну фичу, фичу потом вырезали, а импорт остался — удалить и убедиться, что ничего не сломается, требует времени, а оставить пакет не стоит ничего прямо сейчас. Цена откладывается на потом, и мелкие решения без немедленной цены копятся в большую проблему.

Реальная стоимость мёртвых зависимостей — не место на диске, это несущественно. Реальная стоимость — уязвимости. Каждая библиотека в дереве зависимостей — потенциальная дыра, за которой нужно следить, даже если код давно не используется активно. Сканер находит проблему в пакете, который физически не влияет на приложение, но всё равно требует времени на разбор и патч.

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

Чистый список зависимостей — не эстетика. Это меньше поверхности для атаки и меньше сюрпризов при следующем обновлении.