5 вещей, которые я узнал, доведя Snowpack до 20000 GitHub-звёзд +62



Меня зовут Фред. Я — создатель Snowpack. Для тех, кто не знаком с этим проектом, расскажу в двух словах о том, что он собой представляет. Это — инструмент для сборки фронтенда веб-сайтов, который, по существу, дал дорогу движению «unbundled web development» («веб-разработка, основанная на использовании отдельных компонентов»), которое в наши дни поддерживают Snowpack, Vite, SvelteKit и другие современные инструменты для веб-разработки.

В этом материале я хочу рассказать о пяти вещах, которые я узнал, доведя Snowpack от исходного коммита до почти 20000 звёзд на GitHub и до более чем миллиона загрузок.



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

Мой рассказ состоит из двух частей. В этом первом материале я уделяю основное внимание тому, чему научился, создавая Snowpack с нуля и находя наших первых пользователей. Во второй части я расскажу о том, как выглядит поддержка популярного растущего опенсорсного проекта.

Предыстория


Пару лет назад я начал работу над экспериментальным JavaScript-проектом под кодовым названием Pika. Его талисманом была симпатичная синяя мышка, в этом проекте царила позитивная атмосфера, которая способствовала объединению в его рамках множества более мелких экспериментальных проектов. Общая цель этого проекта лучше всего может быть выражена так: «ES-модули — это замечательная новая технология. Давайте решать с её помощью больше различных задач».

Первый год работы над проектом Pika, возможно, был самым продуктивным годом в моей жизни. Я создал @pika/pack (инструмент для работы над npm-пакетами, рассчитанный на авторов таких пакетов), Pika CI (GitHub-экшн, который позволяет применять команды npm install или даже import() к любому PR на GitHub), неудачный браузерный редактор кода. Я создал и JavaScript-CDN нового поколения, которая, в итоге, превратилась в Skypack.

Среди прочих моих разработок сильнее всего выделялся проект @pika/web. Он позволяет устанавливать любой npm-пакет так, чтобы его можно было бы запускать непосредственно в браузере, не используя при этом бандлер (например — react -> /react.js). Этот проект, вероятно, известен вам под его новым именем (Snowpack).

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

Урок 1: начните с поиска решения какой-то собственной проблемы


В самом начале проект Snowpack представлял собой инструмент для преобразования любого npm-пакета в отдельный JavaScript-файл, код которого можно запустить в браузере. Звучит скучновато. Правда? Нет, не правда!

Этот маленький, незамысловатый инструмент открывал совершенно новый подход к веб-разработке, который сейчас называют «Unbundled Web Development». В результате в распоряжении программистов оказались такие возможности, как мгновенная перезагрузка ресурсов и практически мгновенный запуск проекта в ходе разработки. Работа с ресурсами при этом не замедляется даже тогда, когда число файлов, входящих в проект, доходит до 1000 или даже до более чем 10000. Это ни в какое сравнение не идёт с более традиционными окружениями разработки, где используется бандлинг ресурсов, где всё ещё нормальным считается время запуска и перезагрузки проекта, исчисляемое несколькими секундами.

Исходная идея Snowpack возникла из простого, личного чувства неудовлетворённости, которое я испытывал на работе. Я трудился в команде разработки проекта Polymer, в Google. Там я участвовал в создании альтернативных инструментов сборки для (теперь уже мёртвой) спецификации HTML Imports. Сам инструмент получился весьма приятным, но он не очень хорошо работал с npm, а пользовались им буквально несколько человек.

Я в итоге ушёл из команды разработчиков Polymer, но проблема, которая меня беспокоила, никуда не делась. Почему бандлеры, вроде Webpack, стали единственным инструментом, позволяющим использовать npm-пакеты в браузерах? Что-то должно решить проблемы загрузки npm-пакетов и их запуска в браузере, но должно ли это «что-то» предусматривать бандлинг всего сайта? Snowpack был моей попыткой выяснить то, есть ли альтернативный способ работы с npm-пакетами в браузере.

▍Совет тем, кто занимается поддержкой опенсорсных проектов


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

Урок 2: действуйте быстро, не увеличивайте размеры проекта


Когда вы работаете над новым проектом, вы редко когда знаете о том, какой именно код окажется важным в долгосрочной перспективе, и о том, какой код, в итоге, нужно будет удалить. Я, за время работы программистом, выбросил достаточные объёмы кода для того, чтобы понять, что иногда быстрое, сумбурное написание кода имеет определённую ценность. Если вы начинаете работу над новым проектом, некоторый беспорядок в его коде — это совершенно нормально.

Внутри Snowpack практически все сложные задачи решал Rollup. Snowpack был, на самом деле, всего лишь обёрткой для Rollup, которая занималась бандлингом отдельных npm-пакетов, а не всего сайта. Понимание того, что внутри Snowpack можно задействовать Rollup, сэкономило мне недели (а то и месяцы) рабочего времени.

Если говорить честно, то Snowpack, большую часть своей жизни, представлял собой всего лишь один единственный файл index.js.

Для того чтобы придерживаться избранного курса, я сосредоточился на единственной возможности: «Дай мне имя пакета, а я преобразую его в ES-модуль». Для большинства веб-разработчиков такая возможность, правда, оказалась бы слишком низкоуровневой. Честно говоря, Snowpack не привлёк значительной аудитории до тех пор, пока мы, в его версии 2.0, не добавили в проект встроенный сервер разработки и команду для сборки проекта. Но, даже без сервера, то, что Snowpack 1.0 был узкоспециализированным инструментом, оказалось интересным для определённого класса веб-разработчиков, совсем не пользующихся дополнительными инструментами или пользующимися ими в ограниченных масштабах.

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

  1. Используйте существующие инструменты! Создайте форк похожего опенсорсного проекта или используйте внутри своего проекта существующий инструмент в том случае, если это поможет вам выиграть время.
  2. Пишите неаккуратный код! На самых ранних стадиях развития проекта вы, вероятно, не будете точно знать о том, что именно вы создаёте. Преждевременный рефакторинг кода иногда может быть хуже, чем полное отсутствие рефакторинга. Поэтому постарайтесь как можно дольше поддерживать гибкость своего кода.
  3. Придерживайтесь чётких ориентиров! Не надо оснащать проект недоделанными, едва работающими возможностями. Вместо этого сосредоточьтесь на очень хорошем решении одной задачи.
  4. Не пишите тесты! Сначала убедитесь в том, что создаёте что-то полезное, а потом уже тратьте свободное время на написание тестов. Нет ничего хуже, чем писать тесты для чего-то такого, чем в итоге никто не будет пользоваться.

Я знаю, что некоторые из моих советов выглядят неоднозначно и спорно. «Нет тестов??? Ересь!». Всё, что я могу сказать в защиту своего мнения, заключается в том, что этот подход хорошо сработал на нескольких моих популярных проектах, а так же — на бесчисленном количестве проектов, которые так и не стали популярными и ушли в небытие.

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

Выплата технического долга может оказаться тяжёлой и утомительной работой. Но тут есть и положительный момент: если ваш проект никогда не «взлетит» — значит вы можете принимать поздравления! Вы не тратили время на тестирование чего-то такого, что никому не нужно.

▍Совет тем, кто занимается поддержкой опенсорсных проектов


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

Урок 3: оперативно исправляйте ошибки


Вы только что получили свой первый баг-репорт. Ужас! Кто-то попробовал вашу разработку, а в ней что-то оказалось неисправным. Но самое важное тут то, что ваш проект кого-то настолько заинтересовал, что он сообщил вам об ошибке.

Одной из самых правильных линий поведения при работе над новым опенсорсных проектом является следующая: исправляйте ошибки сразу же после того, как к вам поступают отчёты о них. Сделать исправление ошибок самой приоритетной задачей в проекте, который уже дорос до изрядного размера, довольно сложно. Поэтому, пока можете, наслаждайтесь свободой и возможностью очень быстро реагировать на обращения пользователей.

Себастьян Маккензи (создатель Babel, Yarn, и, теперь, Rome) хорошо выразил вышеозвученную мысль:

Одна из причин успеха Babel заключается в том, как быстро и оперативно я мог исправлять ошибки и выпускать новые версии. Я стремился регулярно выпускать новые релизы в течение считанных минут после получения баг-репортов. Это было невероятно важно в ранние дни развития проекта, когда ещё мало кто им пользовался. Возможность быстро решать проблемы, мешающие пользователям работать, часто могла вдохновить их на использование Babel, несмотря даже на то, что при работе с ним они столкнулись с ошибкой.

▍Совет тем, кто занимается поддержкой опенсорсных проектов


Ваши первые пользователи — это самое важное. Сделайте исправление ошибок, о которых они сообщают, самой главной своей задачей, отодвинув всё остальное на второй план.

Урок 4: уделите внимание хорошему сторителлингу


Возникает такое ощущение, что программисты всегда брезгуют вопросами, связанными с маркетингом. Но ничего не поделаешь — тому, кто хочет, чтобы люди пользовались его разработками, нужно людям об этих разработках рассказать. Даже когда речь идёт о вирусном маркетинге, о «сарафанном радио», когда нечто становится популярным, как кажется, естественным образом, за этим обычно стоят вполне конкретные действия заинтересованных лиц.

Для начала достаточно поделиться сведениями о проекте с друзьями или коллегами и поинтересоваться их мнением о нём. И если ваш проект, в первый же день, не попадёт на первую полосу Hacker News — это совершенно нормально. В этот момент вам нужна лишь обратная связь и, возможно, ваши первые пользователи.

Когда вы готовы к тому, чтобы рассказать о проекте более широкой аудитории, сделать это можно несколькими способами. Один из популярных подходов заключается в том, чтобы рассказывать свою историю постепенно, в небольших, красиво оформленных публикациях. Именно так Себастьян Маккензи разжигал интерес аудитории к Rome, начав почти за 2 года до выхода проекта. Марк Далглейш тоже сделал большое дело, продвигая таким же образом в Twitter vanilla-extract.

Ещё можно проявить креативность и сделать что-то совершенно необычное. Бен Холмс отрывается по полной, записывая видео о своём новом проекте Slinkity перед маркерной доской.

Если говорить о Snowpack, то я решил рассказать нашу историю в одной большой публикации. Её подготовка заняла немало времени, но это дало нам пространство для обстоятельного раскрытия причин существования проекта. Я подумал, что нам нужна эмоциональная связь с нашей главной целью, которая заключалась в изменении подхода к веб-разработке. И даже хотя речь идёт всего лишь об одной публикации, она подняла большой шум, а после того, как она вышла, ещё довольно долго на неё ссылались и делились ей в соцсетях.

▍Совет тем, кто занимается поддержкой опенсорсных проектов


Продвигайте свой проект. Найдите такой стиль сторителлинга, который подходит вам и вашему проекту.

Урок 5: игнорируйте ненавистников, прислушивайтесь к пользователям


Если рассказ о вашем проекте когда-нибудь попадёт на Hacker News — ждите, что кому-то он очень не понравится.

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

Обычно конструктивная критика появляется тогда, когда очевидно то, что некто попытался понять смысл того, что вы сделали, но ещё не вполне разобрался в некоторых важнейших моментах проекта. Легко назвать такого человека тупицей и пойти дальше, но помните о том, что именно вы отвечаете за то, чтобы понятно рассказать другим о своей работе. Если кто-то не понял смысла того, что вы делаете, это обычно значит, что вы могли бы улучшить файл README своего проекта, или его документацию, или как-то поработать над сторителлингом.

▍Совет тем, кто занимается поддержкой опенсорсных проектов


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

Главный вывод: поддерживайте своих первых пользователей


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

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

Есть ли у вас собственные опенсорсные проекты?




Комментарии (26):

  1. Areso
    /#23549166 / +11

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

    Вот числа из моего проекта, за прошлый год:

    9000 людей, запустивших мой проект хотя бы раз

    900 людей, запустивших его повторно

    600 людей, запустивших его на 2-й и далее дни

    +10 звезд

    +4 форка

    +1 контрибьютор

    +1 пиратская копия (да-да, опенсорс тоже можно спиратить).

    • Finesse
      /#23550128 / +4

      Как вы осуществляете мониторинг (собрали эту статистику)?

      • Areso
        /#23550598

        В коде есть два счетчика - Я.Метрики и Гуглоаналитики.

        Они, в том числе, показывают, если моя игра была где-то еще установлена.

        • Finesse
          /#23550642

          Насколько я понимаю, речь идёт о проекте https://github.com/Areso/1255-burgomaster? Тогда всё понятно. Я сначала подумал, что вы говорите про обычную NPM-библиотеку.

          • Areso
            /#23550740 / +2

            NPM-библиотека не для разработчиков была бы чем-то принципиально новым ????

            • Finesse
              /#23550754 / +1

              Для тестировщиков, датасаентистов и других. Но если честно, я проявил невнимательность, не обратив внимание на "не для разработчиков".

  2. SergeiMinaev
    /#23549274 / +3

    Когда для запуска dev-сервера не нужно собирать 50мб бандл - это удобно. Уверен, через несколько лет фронтенд разработка будет вестись с использованием только таких сборщиков. Всё-таки приятно, когда dev-сервер стартует за пару секунд. Правда, лично я использую не Snowpack, а Vite - он мне показался более продуманным. А ещё Vite использует Rollup (который мне кажется очень удобным) и Esbuild, с которым сборка получается ещё быстрее, потому что он написан на Go. В Vite зависимости бандлятся в один большой кусок и не пересобираются, если нет изменений. А внутренний код проекта уже загружается модулями по требованию. Всякие вебпаки после такого кажутся чем-то архаичным и необоснованно медленным.

    • aamonster
      /#23549452

      А как при этом решаются проблемы эффективной доставки пользователю (релизный билд всё-таки бандлится?) и проверки корректности проекта (помню счастье перехода с js на ts)?

      (я достаточно далёк от фронтэнда, но мало ли – и в моих задачах пригодится, ускорить сборку – всегда хорошо).

      • SergeiMinaev
        /#23549460

        Да, prod-версия - как обычно, потому что, даже с учётом http/2, один большой файл загружается быстрее, чем много маленьких.

        • aamonster
          /#23549486

          А проверка корректности? По мне, это даже важнее, бандлинг на крайняк сверху прикрутить можно, а знание, что никто из коллег не поменял сигнатуры функций – бесценно.

          • SergeiMinaev
            /#23549490

            Ну, с TS проблем нет, там он встроенный. По запросу TS-файлик транспилится в JS и передаётся браузеру. В остальном - всё как обычно.

            • aamonster
              /#23549496

              Т.е. об ошибках компиляции ts узнаете лишь зайдя на страницу, где он используется?

              • Alexufo
                /#23549504

                В консоли же или в браузере

              • SergeiMinaev
                /#23549572 / +1

                Кажется, я немного наврал про встроенный TS. Сейчас вспомнил - из коробки делается только транспиляция, а для проверки нужно прикручивать плагин, например, vite-plugin-checker или что-то вручную делать. Проверку можно настроить как угодно, мне кажется. В том числе и авто-проверку при сохранении файла, но я не углублялся в это. Мне в проектах с Vue хватает запуска vue-tsc --noEmit перед коммитом.

                • Alexufo
                  /#23549678

                  да, проверка типов оставлена на вашу уже настроенную IDE либо плагин

                  • Alex_ME
                    /#23584042

                    Когда я последний раз что-то делал под веб фронтенд, там еще было модно использовать Babel для JS, пре- и пост-процессоры CSS. Как я понимаю, это же не будет работать в случае сборщиков, подобных обсуждаемому в статье?

                    Простите, если фигню несу, далек от современного фронта.

                    • Alexufo
                      /#23584128 / -1

                      пре- и пост-процессоры стандарт, внедрились просто чуть глубже во все бандлеры. Бабель почти не нужен уже. es6 уже почти везде. Достаточно просто собирать бандл.
                      Но особенность сборщиков такова — что точно все настраивается. Они не только сборщики js но и всего что есть в вебе. Нужен бабель — в доке указано как.

                      Осталось поведение мудаков типа FF, Safari типа использования
                      import конструкций внутри воркеров.

                      wpt.fyi/results/workers/modules/dedicated-worker-import.any.html?label=master&product=chrome%5Bstable%5D&product=firefox%5Bstable%5D&product=safari%5Bstable%5D&product=chrome%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned

                      Такие кейсы, по-моему, умеет полифилить только вебпак. То есть он может обернуть (с бабелем или нет — не знаю) современные импорты в воркерах в несовременный importScripts() но зато везде рабочий.
                      неприятно так попадать! Везде уже es6 модули как recommended стоят, а в воркерах бах, рано, юзай синхронный importScripts()

        • DIITHiTech
          /#23550020

          Так можно же запилить мультиплексирование, если не на уроне транспорта http2 (если там действительно накладные расходы), то на уровне js загрузчика и специализированного серверного компонента. Я еще 10 лет назад носился с динамическим импортом с мультиплексированием, но тогда нормально не удавалась решить одну проблему- кеширования модулей, из-за отсутствия Cache API и мизерного объема LocalStorage для его эмуляции в 5мб, который весь занимать и нельзя, к тому же он еще тогда не везде был. А модульного кода не было так много, так что захейтили подход.

      • Alexufo
        /#23549502

        Конечно бандлится в прод.

      • Finesse
        /#23550130 / +2

        TS-код всегда можно проверить одной командой:

        npx tsc --noEmit

        Для работы нужно установить NPM-пакет typescript. Запускайте команду в корне проекта где лежит tsconfig.json.

    • Alexufo
      /#23549500 / +1

      Vite сырой ещё для чуть не типичных задач. Например, он не включает в бандл воркеры которые заданы через стандартный es6 new Worker. Ему нужно import worker from .. он не вытягивает все зависимости из подключенной сторонней библиотеки. Postcss с деприкейтнутым синтаксисом.

      Магия и эвристика поиска зависимостей мне не понятна. Я не понимаю как vite тянет зависимости.

      Но мне vite очень нравится

      • SergeiMinaev
        /#23549604

        Грубо говоря, main.ts превращается в main.js и отдаётся браузеру. В main.js делается `import { a } from 'a.ts'`, браузер знает про es6 модули, поэтому отправляет запрос на получение a.ts, а dev-сервер vite, который висит на 3000-м порту, понимает, что перед выдачей a.ts надо его переделать в js.

        У меня вместо встроенного PostCSS отдельный скриптик запускается, который в сторонке собирает SCSS в CSS.

        Про воркеры не знал, спасибо.

        • Alexufo
          /#23549672

          А так же он цепляет сам урлы картинок, других ресурсов в index.html и собирает бандл со всем этим.
          Но почему он не тянет по путям ресурсы подключенные через другой js-ник не понятно.
          SCSS проще тем же vite собирать

  3. Сидел недавно ждал 2 мин прод сборку и думал, что там можно делать с моими 20-тью файлами и из зависимостей Vue+Vuex?