Вибираємо бібліотеку для проєкту

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Вибираємо бібліотеку для проєкту. Цю інформацію ви також можете прочитати в моєму лінкеді.

Доцільність. Додавання сторонньої залежності має бути обгрунтованим. Вам цю бібліотеку потім апдейтити, боротися з багами, слідкувати за вразливостями. Тому, якщо функціонал, який вам потрібен, маленький та простий — краще зробити самому.

Бібліотека має виконувати задачу. Беремо функціонал, який ви вважаєте найскладнішим і шукаєте його в документації. Якщо з документації не все очевидно, або задача складна — зробіть proof of concept, щоб позбавитися сумнівів

Бібліотека має бути відносно популярна. Що популярніша бібліотека, то більше по ній додаткових матеріалів та людей, що прийдуть вам на допомогу в разі проблем. Плюс більше шансів, що популярна бібліотека буде мати зручний дизайн та буде протестована (але це не точно). Перевірити це можна за «зірками» в GitHub та кількістю завантажень в npm.

Бібліотека має підтримуватися. Відкрийте репозиторій та npm, перевірте останню активність. Якщо активності немає протягом тривалого часу (більше пів року), а issue багато — це поганий знак. Ми так влізли в халепу з UI-бібліотекою, яка «застрягла» на React 17. Snyk показує рівень «здоровості» пакету, але бажано розуміти самому, що там так або не так.

Бібліотека має бути без вразливостей. Якщо це dev-залежність, цей пункт можна спробувати ігнорувати, але за умови, що вразливість не є бекдором або іншою схожою на це халепою. Якщо ви не впевнені, краще не ігнорувати.

Бібліотека має бути відносно маленька. Відносно, тому що якщо складні речі можуть потребувати багато коду. Але бібліотека, яка лише перевіряє чи є щось об’єктом, не може важити 100Kb. Зрештою сам react-dom важить 130Kb. Пам’ятайте, що для проєктів, де швидкодія критична — у вас є приблизно 350kb для JavaScript в gzip. Якщо ви пишите адмінку, цей пункт можна пропустити.

Тож коли обираєте собі бібліотеку, можете зробити собі табличку з цих пунктів для порівняння. Заодно задокументуєте, чому було обране те чи інше рішення.

До речі, не потрібно шукати бібліотеку на все підряд

Для прикладу ось бібілотека — is-object, яка має 3,4M завантажень на тиждень і зводиться до одного єдиного рядка:

const isObject = (obj) => typeof obj ==='object' && obj !== null;

Такі або подібні до цього речі варто робити самому, тому що кожна додаткова бібліотека вимагає:

Догляду. У бібліотеках бувають баги, бувають вразливості — відповідно вам треба оновлюватися і за цим стежити. Звісно, у власному коді теж бувають і баги, і вразливості, але коли весь код у вас — виправити простіше. Та й бекдор під час наступного оновлення ви не встановите.

Місця. Код, який написали ви — використовується на 100%. А якщо ви берете з lodash один єдиний метод, все інше просто сповільнює ваш застосунок (так, навіть якщо прямо не використовується). Це не запас на випадок кризи — «про всяк випадок» тут не працює.

Часу в пайплані. Кожна додаткова бібліотека це + до install часу. І якщо на початку це не критично, потім це дуже дратує, коли білд на сервері йде 18 хвилин, а без нього PR з виправленням однієї літери не проходить.

Тому підходьте до питання з розумом: складний функціонал беремо з бібліотек, щось просте — робимо самостійно. Ну не вірю я, що ви б не змогли написати код з прикладу вище самостійно💪

Я не хейчу подібні бібліотеки, у самого є така is-number-strict :)

Бережіть себе, допомагайте ЗСУ!