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

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

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

Причём проект может проходить цикл повторно. Например, если изменилась прикладная цель или пришёл новый овнер, проект может пойти на новый круг по спирали.

Сам цикл может проходить быстро, если проект — это mvp со сроком жизни в месяц, или долго, когда проект долгоиграющий (Linux 👋).

Так вот, к зависимостям.

Гвард 1. О качестве зависимости можно не задумываться, если срок жизни вашего проекта будет короче, чем срок жизни зависимости. И, наоборот, качество зависимости очень важно, если ваш проект — долгий: зависимости нужно будет обслуживать и утилизировать в случае заброшенности, либо дорабатывать форк. Чем зависимостей больше, тем больше времени будет уходить на обслуживание.

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

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

🍿 Часто бывает, что зависимость выбирается по популярности. Типа «миллионы юзеров не могут ошибаться».Да, у популярного проекта большее сообщество, больше контрибьюторов, но бывает, что что-то становится модным, а затем мода на это проходит. Тут можно смотреть на количество звёзд, форков, подписчиков, контрибьюторов, скачиваний (а также тренд скачиваний).

👥 Мейнтейнер(ы) и мейнтейн. Если мейнтейнер один, то вероятность стать заброшенным у проекта больше, так как бас фактор. Мейнтейн можно оценить по соотношению открытых/закрытых ишью, времени закрытия ишью, времени последнего обновления и частоте релизов.

🛠️ Качество инфраструктуры. Документация, настроенный линтер, тесты, внятное версионирование. Тут всё ясно.

⛓️ Зависимость от других зависимостей. Чем больше зависимостей, тем хуже. Энтропия увеличивается, всё остальное падает. Одиночные пакеты лучше, но есть исключение, когда речь идёт о целой экосистеме, например, ui-ките, который вы целиком используете.

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

🧭 DX. Если проект будет минимального размера и без внешних зависимостей, но при этом него будет неудобный API, то не стоит брать его. Нервы дороже.

💸 Финансирование. Если у проекта есть платная версия или же за ним стоит зарабатывающая компания, то вероятность более длинной жизни проекта больше. Без поддержки энтузиазм быстрее заканчивается.

Как теперь это всё отслеживать, спросите вы. Для этого есть инструменты.

Оценить размер бандла, увидеть вложенные зависимости и сравнить с аналогами можно на bundlephobia (пример).

Увидеть «рейтинг» пакета можно на npms (пример). Там оценивается «качество», «популярность» и «мейнтейн». Так же можно сравнить с аналогами.

Более детально проанализировать зависимости можно на npmgraph. Например, можно оценить количество мейнтейнеров в дочерних зависимостях, актуальность зависимостей, оценку npms.

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