Как можно сделать существующую библиотеку легче? Вариантов много, но начал бы со следующих пунктов:
1. Удалить зависимости или заменить их на более легкие.
Пример: заменить moment на date-fns (или на стандартный Date) или styled-components на какой-нибудь goober.
2. Настроить tree-shaking, чтобы неиспользуемый код зависимости не попадал в бандлы сайтов. Особенно актуально если библиотека предоставляет множество различных экспортов (как lodash).
По сути, нужно просто настроить поле sideEffects в package.json.
3. Если пакет публикуется в виде транспилированного кода, то "упростив" исходный код можно избавиться от лишних полифиллов.
Отбрасывание современных "фишек" (классы, async/await, генераторы, spread-операторы и тд) значительно уменьшает вес того, что "выдает" Babel.
Например, ощутимо помогает замена классов на функции, так как Babel трансформирует классы в "колбасу" из кода. К тому же, названия методов у классов не минифицируются
В случае с Реактом, переписав все на хуки и функциональные компоненты, можно сделать бандл легче почти в 2 раза
4. Также, из того что еще сразу приходит в голову, можно сделать легче сам пакет, чтобы ускорить его установку и время на CI. Для этого можно настроить .npmignore, а еще лучше поле files в package.json.
В 2016 году, когда велась работа над MVP нашего продукта, ребятам был нужен быстрый и легкий способ внедрить генерацию PDF, при этом не вводя другие технологии, языки и т.д.
👇
Бекенд resume.io работал и работает на Rails, поэтому ребята нашли гем Wicked PDF, который генерирует PDF на основе HTML+CSS, что идеально нам подходило.
Wicked PDF — это ruby-обертка над CLI-инструментом wkhtmltopdf, который под капотом работает с Qt Webkit. Последний стал для нас причиной проблем, но об этом позже.
Чтобы разработчики начали использовать ваш пакет в продакшене, информация о вашей либе должна внушать им уверенность. Обычно, люди видят, что у пакета много скачиваний и им этого достаточно, но у новой библиотеки им взяться неоткуда. Проблема курицы и яйца.
👇
Без популярности неоткуда взяться установкам, а без них нет доверия, которое нужно для популярности.
Нужно, чтобы появились проекты, которые используют вашу библиотеку.
GitHub покажет их в "Used by", а NPM — в Dependents. И они же дадут первые цифры по установкам.
Если ваша библиотека только вышла, то вряд ли кто-то сам найдет и установит ее.
Но никто не мешает вам найти через GitHub и NPM проекты, которые используют более тяжелые аналоги и сделать PR, заменяющий их на ваш пакет.
Сразу скажу, что я не особо известный разработчик. Летом у меня было всего 200 подписчиков, но за пару месяцев получилось пропиарить библиотеку так, что меня позвали и в подкаст Веб-стандарты, и в jsunderhood.
👇
Если считаете, что нужно быть "звездой", чтобы ваш проект начали использовать, то это не так. Разумеется это поможет, но у меня вроде неплохо получилось без 5k подписчиков и всемирной известности. Многое зависит от того, сколько сил вы готовы вложить именно в продвижение.
Советую посмотреть доклад @andrey_sitnik о продвижении опен-сорс проектов, так как многие вещи я оттуда использовал лично и они реально пригодились.
Если рассматривать различные микро-оптимизации веса бандла, то выделил бы следующие:
1. Помимо классов, по возможности лучше не использовать и объекты, так как названия ключей в них обычно не минифицируются, а если используете, старайтесь делать ключи покороче.
А еще лучше попробовать разбить объект на отдельные переменные: названия переменных отлично минифицируются.
Кстати, если ваша библиотека подразумевает настройку с помощью конфиг-объекта, то лучше сразу придумать названия ключей покороче. Потом поменять их без breaking changes будет нельзя.
Также, если избегать вещей, которые плохо минифицируются, требуют полифиллов или трансформация кода, то можно заметно снизить вес вашей библиотеки после сборки.
Примеры:
👇
1. Лучше использовать функции вместо классов. Функциям не нужна трансформация и, к тому же, в отличие от классов, они хорошо минифицируются. Избавившись от классов целиком может получится сделать итоговый минифицированный код в 2 раза легче.
2. Используйте обычные Promise, вместо async/await и генераторов. Хоть исходный код с async/await или yield и занимает меньше строк кода, но после трансформации эти участки кода будут весить во много раза больше, чем аналогичный код на промисах.
Как добиться того, чтобы вес библиотеки был небольшим?
Многое, конечно, зависит от задачи, но первым универсальным пунктом я бы выделил "Не использовать зависимости пока это возможно".
👇
Причин избегать зависимостей в ваших пакетах просто уйма. По сути из-за добавления зависимостей вам станет сложно гарантировать вес и качество вашего пакета:
1. Зависимости могут стать уязвимыми или вообще исчезнуть (пока left-pad).
Второе конечно маловероятно, но первое достаточно частый кейс, который "подкидывает" лишние работу и переживания, как разработчикам, так и пользователям библиотек.