Окей, на GH и NPM метрик маловато, как же тогда оценить пакет не ковыряясь полдня в репозитории и не устанавливая его в свой проект?

На помощь приходят такие классные сервисы и инструменты как:
bundlephobia.com
npm.anvaka.com
— npm-consider
1) Проект bundlephobia.com я очень люблю и пользуюсь им почти каждый день. Здесь можно получить такую информацию как: вес импорта JS-кода (min и gzip), число прямых зависимостей и поддержка tree-shaking.
Также очень полезно посмотреть распределение веса. Зачастую авторы библиотек выбирают зависимости так неудачно, что для маленьких опциональных фич используются зависимости, которые весят в несколько раз больше кода самого пакета.

Пример: bundlephobia.com/result?p=react…
Кстати, bundlephobia.com ведет что-то вроде библиотеки аналогов пакетов. Если вы знаете легкую альтернативу к какому-нибудь популярному пакету, можете сделать issue в репозитории bundlephobia.
Кто-то скажет, что так открыто предлагать альтернативы это немного токсично. Я лично считаю, что надо дать пользователю возможность выбрать. Если популярный пакет реально лучше, то он все равно выберет его, а не альтернативу.

Подобная конкуренция должна хорошо влиять на качество
2) Если не хочется заходить на сайт бандлфобии, то есть браузерный extension, который работает с их API и добавляет отображение min и gzip размеров прямо на сайты NPM и GH.

github.com/vicrazumov/js-…
3) Переходим к сервису npm.anvaka.com, который обожаю не меньше. Этот сервис рекурсивно строит граф зависимостей и показывает сколько всего вы притащите с свой node_modules.
Результаты могут вас, мягко говоря, удивить. Например, у пакета react-input-color шесть прямых зависимостей, но итоговое дерево его зависимостей включает больше 80 пакетов.
На меня, кстати, сильно влияет то, с какой такой анимацией тут строится граф: как будто какой-то вирус распространяется. Еще сильнее отбивает желание устанавливать пакеты с кучей зависимостей.
4) Если вдруг npm.anvaka.com не работает (у них иногда бывает), можете воспользоваться сайтом npm.broofa.com — почти тоже самое, но менее удобно (IMHO), зато с отображением баллов npms.io (про них чуть позже).
5) Для любителей CLI-инструментов, могу предложить npm-consider. Не особо популярный инструмент, но с кучей полезных функций.

Запуская npm-consider install вместо npm install, вы можете перед установкой просмотреть граф зависимостей и оценить их размер.

github.com/delfrrr/npm-co…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with jsunderhood

jsunderhood Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jsunderhood

21 Oct
В 2016 году, когда велась работа над MVP нашего продукта, ребятам был нужен быстрый и легкий способ внедрить генерацию PDF, при этом не вводя другие технологии, языки и т.д.

👇
Бекенд resume.io работал и работает на Rails, поэтому ребята нашли гем Wicked PDF, который генерирует PDF на основе HTML+CSS, что идеально нам подходило. Image
Wicked PDF — это ruby-обертка над CLI-инструментом wkhtmltopdf, который под капотом работает с Qt Webkit. Последний стал для нас причиной проблем, но об этом позже.

wkhtmltopdf.org Image
Read 6 tweets
20 Oct
Чтобы разработчики начали использовать ваш пакет в продакшене, информация о вашей либе должна внушать им уверенность. Обычно, люди видят, что у пакета много скачиваний и им этого достаточно, но у новой библиотеки им взяться неоткуда. Проблема курицы и яйца.

👇 Image
Без популярности неоткуда взяться установкам, а без них нет доверия, которое нужно для популярности.

Нужно, чтобы появились проекты, которые используют вашу библиотеку.

GitHub покажет их в "Used by", а NPM — в Dependents. И они же дадут первые цифры по установкам. Image
Если ваша библиотека только вышла, то вряд ли кто-то сам найдет и установит ее.

Но никто не мешает вам найти через GitHub и NPM проекты, которые используют более тяжелые аналоги и сделать PR, заменяющий их на ваш пакет. Image
Read 10 tweets
20 Oct
Коротко о продвижения микро-библиотек.

Сразу скажу, что я не особо известный разработчик. Летом у меня было всего 200 подписчиков, но за пару месяцев получилось пропиарить библиотеку так, что меня позвали и в подкаст Веб-стандарты, и в jsunderhood.

👇
Если считаете, что нужно быть "звездой", чтобы ваш проект начали использовать, то это не так. Разумеется это поможет, но у меня вроде неплохо получилось без 5k подписчиков и всемирной известности. Многое зависит от того, сколько сил вы готовы вложить именно в продвижение.
Советую посмотреть доклад @andrey_sitnik о продвижении опен-сорс проектов, так как многие вещи я оттуда использовал лично и они реально пригодились.

Read 14 tweets
20 Oct
Если рассматривать различные микро-оптимизации веса бандла, то выделил бы следующие:

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

👇
Вместо какого-нибудь { totalAmountOfPages: 1 } напишите { pageCount: 1 }.

А еще лучше попробовать разбить объект на отдельные переменные: названия переменных отлично минифицируются. Image
Кстати, если ваша библиотека подразумевает настройку с помощью конфиг-объекта, то лучше сразу придумать названия ключей покороче. Потом поменять их без breaking changes будет нельзя. Image
Read 8 tweets
20 Oct
Также, если избегать вещей, которые плохо минифицируются, требуют полифиллов или трансформация кода, то можно заметно снизить вес вашей библиотеки после сборки.

Примеры:
👇
1. Лучше использовать функции вместо классов. Функциям не нужна трансформация и, к тому же, в отличие от классов, они хорошо минифицируются. Избавившись от классов целиком может получится сделать итоговый минифицированный код в 2 раза легче. ImageImage
2. Используйте обычные Promise, вместо async/await и генераторов. Хоть исходный код с async/await или yield и занимает меньше строк кода, но после трансформации эти участки кода будут весить во много раза больше, чем аналогичный код на промисах. Image
Read 5 tweets
20 Oct
Как добиться того, чтобы вес библиотеки был небольшим?

Многое, конечно, зависит от задачи, но первым универсальным пунктом я бы выделил "Не использовать зависимости пока это возможно".

👇
Причин избегать зависимостей в ваших пакетах просто уйма. По сути из-за добавления зависимостей вам станет сложно гарантировать вес и качество вашего пакета:
1. Зависимости могут стать уязвимыми или вообще исчезнуть (пока left-pad).

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

Меньше зависимостей — спокойней жизнь.
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!