Tweet

jsunderhood

20 Oct, 10 tweets, 3 min read

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

👇

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

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

GitHub покажет их в "Used by", а NPM — в Dependents. И они же дадут первые цифры по установкам.

Если ваша библиотека только вышла, то вряд ли кто-то сам найдет и установит ее.

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

Эти проекты не обязательно должны быть какими-то супер-популярным. На стартовом этапе важно, чтобы у вашей библиотеки просто было видно хоть какое-то комьюнити. Это добавит разработчикам уверенности, что вашу библиотеку можно использовать. А дальше уже цепная реакция.

Разумеется, шанс, что PR-ы примут — не очень высок, а делать их при этом очень сложно (нужно развернуть и запустить незнакомый проект, разобраться в его коде и т.д). Особенно тяжело, когда API вашей библиотеки отличается от API пакета, который вы хотите заменить.

Если у вас хорошее README, демка и вы хорошо описали пользу для проекта от вашего PR, то шансы конечно выше.

Сразу делать PR-ы в крупные проекты наверное не стоит. Начните, например, с простых инструментов/сайтов, которые разработчики делают для других разработчиков.

Точно не будет лишним отметить проекты, которые используют вашу библиотеку, в README и, по возможности, "приправить" все это цитатой какого-нибудь известного разработчика.

Мне немного повезло, так как я изначально сделал колор-пикер как рабочую задачу для resume.io, а уже потом мы его заопенсорсили. Так что в моем README сразу красовался проект с аудиторией в 8 млн пользователей.

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

Это, к тому же, даст вам хоть какой-то, но стабильный объем скачиваний в NPM.

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

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

• • •

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

This Thread may be Removed Anytime!

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

More from @jsunderhood

jsunderhood

@jsunderhood

21 Oct

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

👇

Бекенд resume.io работал и работает на Rails, поэтому ребята нашли гем Wicked PDF, который генерирует PDF на основе HTML+CSS, что идеально нам подходило.

Wicked PDF — это ruby-обертка над CLI-инструментом wkhtmltopdf, который под капотом работает с Qt Webkit. Последний стал для нас причиной проблем, но об этом позже.

wkhtmltopdf.org

Read 6 tweets

jsunderhood

@jsunderhood

20 Oct

Коротко о продвижения микро-библиотек.

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

👇

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

@andrey_sitnik

Советую посмотреть доклад @andrey_sitnik о продвижении опен-сорс проектов, так как многие вещи я оттуда использовал лично и они реально пригодились.

Read 14 tweets

jsunderhood

@jsunderhood

20 Oct

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

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

👇

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

А еще лучше попробовать разбить объект на отдельные переменные: названия переменных отлично минифицируются.

Кстати, если ваша библиотека подразумевает настройку с помощью конфиг-объекта, то лучше сразу придумать названия ключей покороче. Потом поменять их без breaking changes будет нельзя.

Read 8 tweets

jsunderhood

@jsunderhood

20 Oct

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

Примеры:
👇

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

2. Используйте обычные Promise, вместо async/await и генераторов. Хоть исходный код с async/await или yield и занимает меньше строк кода, но после трансформации эти участки кода будут весить во много раза больше, чем аналогичный код на промисах.

Read 5 tweets

jsunderhood

@jsunderhood

20 Oct

Как добиться того, чтобы вес библиотеки был небольшим?

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

👇

Причин избегать зависимостей в ваших пакетах просто уйма. По сути из-за добавления зависимостей вам станет сложно гарантировать вес и качество вашего пакета:

1. Зависимости могут стать уязвимыми или вообще исчезнуть (пока left-pad).

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

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

Read 10 tweets

jsunderhood

@jsunderhood

20 Oct

Давайте наконец перейдем к тому, как разрабатывать микро-библиотеки.

Если вы нашли какую-то проблему или сферу для которой вы можете создать новое lightweight-решение, то не рекомендую сразу писать код, — начните с формирования целей и ограничений.

👇

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

Перед разработкой react-colorful я поставил себе цель сделать импорт своего компонента минимум в 10 раз легче, чем у react-color.

Почему это важно?

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

Read 10 tweets

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!