В этом треде поделюсь опытом трех лет поддержки библиотеки веб-компонентов в open source и расскажу о превозмогании трудностей.
Как я уже упоминал, компоненты Vaadin написаны на Polymer. Почти весь код до сих пор на Polymer 2 и поэтому использует Bower. Так что поддерживать приходится больше 40 репозиториев на GitHub.
Для конвертации в Polymer 3 у нас есть CLI-утилита. Любая версия компонента доступна в Bower и npm одновременно, но при этом код там разный. С точки зрения semver это выглядит весьма странно.
Подход, где каждый компонент — отдельный npm пакет, имеет свои недостатки. Например, нужно следить за версиями, чтобы избежать дубликатов зависимостей, иначе в приложении будут ошибки.
Кроме того, мы поддерживаем несколько минорных версий и иногда бэкпортим фиксы. В таких случаях важно следить за npm dist-tag, чтобы более ранняя минорная версия не получила тег latest.
Количество репозиториев тоже создает сложности. Мажорные версии нужно релизить в правильном порядке, обновляя при этом зависимости. У нас есть скрипты, чтобы не делать все вручную.
Надеюсь, в будущем удастся перевести разработку библиотеки в монорепу и унифицировать версии. Для API компонентов на Java мои коллеги это уже сделали, это сильно упростило процесс релиза.
Задача осложняется тем, что у Vaadin есть LTS-релизы и компоненты на Polymer 2 нашей команде предстоит поддерживать еще несколько лет (хотя версия на HTML Imports по факту уже год как deprecated).
Много репозиториев = много билдов в CI. Мы пока используем Travis, а у него лимит 5 free jobs на организацию. Отправив PR, можно идти пить кофе, хотя чаще всего приходится ждать сильно дольше.
Недавно в Travis объявили об изменении ценовой модели. Вкратце, безлимит для open source проектов заканчивается. Дополнительные бесплатные минуты обещают выдавать после рассмотрения запроса.
blog.travis-ci.com/2020-11-02-tra…
Мы постепенно переходим с Travis на GitHub Actions. Пока общее впечатление положительное. Огорчает отсутствие возможности перезапустить отдельный job (можно только workflow целиком).
github.community/t/ability-to-r…
Для тестирования мы используем SauceLabs. У них есть бесплатный план для open source по запросу. Правда, как-то раз от них пришел email с жирным намеком, что их щедрость имеет свои границы.
@jsunderhood Как у вас работают скриншотные тесты? Визуальный дифф в консоль не вывести. Как смотреть результаты сравнения в Travis и GithubActions?
Насчет тестов скриншотами: с этим у нас пока все печально. Каждый раз приходится смотреть локально, что именно сломалось. Надеюсь, когда-нибудь у нас дойдут руки интегрировать Argos CI.
twitter.com/justboriss/sta…
При разработке на GitHub важен удобный project board. Несколько лет назад мы использовали Waffle, идеально подходивший для наших задач. К сожалению, этот сервис уже давно недоступен.
После Waffle пробовали GitHub Projects, там оказалось несколько недостатков: не было возможности связать issue и PR, отсутствовали status checks. Пришлось перейти на ZenHub как меньшее зло.
Разработка продукта в open source подразумевает коммуникацию с теми, кто его использует. Это полезно в смысле выявления багов, также можно получить полезный фидбек, иногда он вдохновляет.
Иногда коммуникация с сообществом позволяет найти кандидатов, которые впоследствии присоединятся к команде. Я сам был одним из контрибьюторов, а в итоге получил оффер в Vaadin.
Для общения у нас есть канал в слаке Polymer Project. Там иногда появляются мейнтейнеры lit-html, в том числе Justin Fagnani. Свой канал там есть также и у проекта Open Web Components.
polymer-project.org/slack-invite
В прошлом мы в Vaadin также использовали Gitter. На мой взгляд, он был удобен только ссылками на issue. Никаких особых улучшений за 3 года там не появилось. В итоге недавно мы перешли на Discord.
discord.gg/PHmkCKC
Немного о процессах. Раз в неделю мы просматриваем новые issue, стараемся на них отвечать и добавляем метки. Также каждую неделю один из нас поочередно следит за вопросами в Slack и Discord.
Иногда бывает и так, что доходят руки до issue, висевшего без ответа несколько месяцев. Я в таких случаях всегда испытываю дискомфорт, даже если причина в не совсем корректной формулировке.
Когда issue много, они превращаются в груз, который производит угнетающее впечатление. Простой способ "решить" проблему — настроить stale bot, но мы пока еще к этому не готовы.
Единственный способ разгрести груду тикетов — постоянство и автоматизация. Помогает даже использование меток. Еще очень важно наличие в проекте issue template, а лучше нескольких.
Улучшения требуют времени. У нас в Vaadin для этого есть Community Friday: пятница в конце двухнедельного спринта. В этот день можно заниматься и своими опенсорс-проектами, это приветствуется.