Интенсивное начало года не оставляет шансов для написания больших заметок, поэтому продолжаем серию коротышей. Интенсивное начало года требует обращения к наработкам других разработчиков и использования их продуктов. Поэтому всё чаще я занимаюсь выбором каких-либо npm-пакетов для нашего проекта. И, кажется, разработал алгоритм который отлично работает для меня.
Не претендую на оригинальность, просто формализую свой опыт. Допустим, у меня есть задача отрисовки графиков на основном дашборде и несколько пакетов которые, кажется, решают эту проблему одинаково хорошо. Но остаться должен только один. Передо мной открыто три вкладки с npmjs.com, на каждой — информация о том или ином пакете. Вот как буду выбирать.
Шаг 1. Насколько новая зависимость раздует бандл?
Каждая новая зависимость попадет в директорию node_modules. Каждая новая зависимость добавит в итоговый бандл какое-то дополнительное количество байт или даже килобайт, ведь по сути, импортируя к себе что-то из этих зависимостей, мы говорим сборщику добавить этот код в бандл. И все бы хорошо, но этот код так же может использовать какие-то другие зависимости. А те — другие. В итоге ваш итоговый бандл может распухнуть. Поэтому в самом начале нужно оценить следующее
- Размеры пакета (они конечно указаны на npmjs, но чтобы оценить влияние на бандл, можно посмотреть делатльную информацию на стороннем сервисе, например на https://bundlephobia.com/)
- Список его зависимостей (загляните в package.json на гитхабе)
Для обоих критериев действует правило — чем меньше, тем лучше.
Шаг 2. Сколько людей уже использует этот пакет?
Если коммьюнити активно использует то или иное решение, оно обречено на развитие. Это косвенный признак «хорошести». Конечно, можно возразить, что миллионы мух не могут ошибаться. Но эти самые миллионы мух уже решили писать сложные приложения на JS, поэтому работаем с тем, что имеем.
И если вдруг пакет перестанет решать задачу лучше других, количество его недельных загрузок, указанное на том же npmjs.com пойдет вниз. К слову, если есть время, можно проанализировать как росла или падала популярность решения, сравнив с чейнджлогом и историей релизов.
Шаг 3. Как давно обновлялся пакет?
Мы оценили уже достаточно факторов, чтобы отсеять неудачные решения. Остался последний, после которого мы выявим победителя. Частота обновлений — признак жизненной силы, способности проекта меняться вместе с фронтендом. Брошенные проекты — не круто, те которые обновляются ежедневно — скорее подозрительно, чем хорошо.
Я бы прошел мимо решений, которые не обновляются годами. Их уже давно известные уязвимости и нерешенные баги станут уязвимостями и багами вашего проекта.
Дополнительно можно проверить список ишью на гитхабе проекта. Шанс что проект написан так идеально, что не требует обновления ничтожно мал, но никогда не равен нулю. Заодно сможете оценить как мейнтейнеры работают с фича реквестами со стороны пользователей.
До сих пор не приняли решения?
Значит «быстро не получится». На этом этапе я бы полез в документацию, чтобы изучить API оставшихся в шорт-листе решений и выбрал бы то, которое кажется наиболее подходящим для решения моей задачи. К слову, красивая и понятная документация — так же признак любви разработчиков к своему продукту и может быть сильным аргументом за то или иной решение.
