Что такое зависимость — и почему одна библиотека тянет двести

Ты просишь агента добавить в проект одну маленькую штуку — например, красиво показывать даты. Он ставит одну библиотеку. Ты смотришь в папку проекта, а там сто девяносто пакетов.

Ты не ошибся и агент не сошёл с ума. Так и работает.

И вот что из этого следует, а замечают редко: в твоём проекте почти наверняка больше чужого кода, чем твоего. В десятки раз. А отвечать за него, когда он сломается, будешь ты.

Что такое зависимость простыми словами

Зависимость — это чужой код, от которого зависит твой.

Буквально: без него твоё приложение не запустится. Не «будет хуже», а не запустится.

Ты его не писал и, скорее всего, никогда не читал. Ты просто сказал «мне нужно показывать даты по-человечески», и менеджер пакетов скачал чужое решение в папку рядом с твоим кодом.

Список таких штук лежит в отдельном файле проекта. В мире JavaScript это package.json, в Python — requirements.txt или pyproject.toml. Файл маленький: обычно 5–15 строчек. Именно из-за этого и возникает иллюзия, что зависимостей мало.

Почему одна библиотека тянет за собой двести

Потому что автор твоей библиотеки — тоже человек. И он тоже не хотел писать всё сам.

Получается цепочка:

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

Твои 5–15 строчек в файле — это прямые зависимости: то, что ты выбрал сам. Всё, что они притащили следом, — транзитивные: ты их не выбирал и обычно даже не знаешь их названий.

Отсюда ответ на вопрос «почему папка весит больше, чем весь мой код». Ты видишь верхушку списка, а ставится всё дерево.

Зависимость — это не «скачал», а «буду скачивать»

Вот место, где ломается интуиция новичков. Кажется, что библиотека — это файл, который один раз скачали, и он лежит.

Нет. В файле проекта записано не «эта библиотека», а правило, по какой версии её брать. Запись вида ^4.17.1 означает примерно «версия 4, не ниже 4.17.1, свежие мелкие обновления бери».

Что это значит на практике: ты собираешь проект сегодня — приезжает 4.17.1. Собираешь через полгода на другой машине — может приехать 4.22.0. Код твой не менялся, а проект собрался другой.

Именно поэтому рядом появляется второй файл — package-lock.json или аналог. Он фиксирует точные версии всего дерева, включая транзитивные. Его коммитят в репозиторий, и его не надо чистить «чтобы не мешался»: это единственная запись о том, из чего собрался работающий проект.

Отсюда же одна из самых частых поломок сборки — когда файл со списком и файл с фиксацией разошлись. Разбор симптомов есть отдельно: почему падает npm install.

И ещё одно следствие, менее очевидное. Раз код приезжает из интернета при каждой установке — он может оттуда и исчезнуть. В 2016 году автор удалил из npm крошечный пакет на одиннадцать строк, который добавлял пробелы в начало строки. Сборки у тысяч проектов по всему миру встали в тот же день — потому что он лежал где-то глубоко в дереве у половины популярных библиотек.

Ставить или написать самому

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

Три вопроса перед установкой:

1. Сколько кода я впускаю ради того, что мне нужно? Если пакет делает одну функцию, которую ты напишешь за десять строк, — напиши за десять строк. Если он делает работу с часовыми поясами — ставь, там ад, и ты в нём утонешь.
2. Он живой? Посмотри дату последнего обновления и открытые проблемы. Пакет, который не трогали три года, — это код, который ты будешь чинить сам.
3. Что будет, если он сломается? Библиотека для кнопки — переживёшь. Библиотека, через которую ходят деньги или пароли, — совсем другой разговор.

Отдельный совет для работы с агентом. Модели любят ставить пакеты: это самый короткий путь к рабочему ответу. Проси прямо: «реши без новых зависимостей, а если без них никак — объясни почему». Часто выясняется, что можно без них, а ты просто не спрашивал.

Практическая привычка: раз в пару месяцев открывай список прямых зависимостей и читай его вслух. Всё, чему ты не можешь объяснить назначение за одну фразу, — кандидат на удаление. Обычно из десяти пунктов лишними оказываются два.

Чем зависимость отличается от библиотеки?

Библиотека — это сам чужой код. Зависимость — это отношение: твой проект без неё не работает. Одна и та же библиотека для тебя зависимость, а для того, кто её не ставил, — просто библиотека.

Можно ли удалить папку с зависимостями?

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

Что такое уязвимость в зависимости?

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