👋 Я Виталий Слободин, Senior Frontend Engineer в GitLab. Мне задают много вопросов о работе в GitLab и я решил последовать современному тренду и создать Telegram канал. В этом канале будут публиковаться новости или заметки из жизни разработчика в GitLab. Новости не будут ограничены только одним направлением (Frontend), они будут про все команды и направления, также будут технические посты и заметки про разработку в целом. Вопросы можно задавать в телегу - @vitallium.

Как мейнтейнеру GitLab мне часто приходится работать с нашей конфигурацией ESLint: добавлять/удалять правила, создавать свои, производить оптимизации. Так, например, холодный запуск ESLint на все файлы в GitLab занимает около 4 минут. Довольно много и за этим приходится следить. Так вот, у ESLint есть поддержка замечательной переменной окружения TIMING - env TIMING=1 eslint. При помощи нее можно получить вот такую таблицу с правилами, на которые уходит больше всего времени и на которые нужно обратить внимание в первую очередь.

Про Code Review

Я заметил, что команду разработчиков GitLab часто спрашивают, как мы делаем код-ревью. Самая простая схема, которую я встречал в других компаниях, выглядела так: merge request (или патчи изменений), CI и проверка человеком. В GitLab процесс построен по-другому. В этих заметках я опишу схему код-ревью и поделюсь ссылками на нашу документацию.

Проверка кода начинается с того, что автор предлагаемых изменений создает merge request. Автором может быть не только сотрудник компании, но и любой другой человек, так как наш продукт — программное обеспечение с открытым исходным кодом. После создания merge request автоматически запускается pipeline (конвейер): он проверяет код на огромное количество параметров, запускает тесты и, если надо, создаёт review app. Ещё есть Danger bot, который по запрограммированным критериям выбирает разработчиков для проверки кода по направлению: frontend, backend, автоматизированные тесты и документация.

На каждое направление бот назначает двоих — ревьювера (reviewer) и мейнтейнера (maintainer). Задача ревьювера провести первоначальную проверку merge request, далее он передаёт его мейнтейнеру. Здесь не просто работает пословица "Одна голова хорошо, а две еще лучше!". Это связано ещё с тем, что ревьювер может не знать проверяемую часть продукта и не увидит несостыковки в бизнес логике. У мейнтейнера такие знания есть, но и он может что-то упустить. Его задача — проверить код, исходя из задач продукта и инфраструктуры.

Помимо автоматизации, есть ручная проверка. Автор назначает сотрудников из других групп: UX, если есть изменения в интерфейсе, или дизайнера для проверки серьёзных изменений в дизайне или уточнения требований. Когда этот этап закончили, последний из проверяющих мейнтейнеров запускает pipeline ещё раз. Это нужно, чтобы проверить результаты слияния merge request с веткой main. Если всё хорошо, то merge request вливается в общую кодовую базу.
Интересно, что в компании есть специальные люди, которые входят в группу Merge Request Coach. Они обучают и консультируют тех, кто хочет улучшить навыки проверки кода.

Пока пост про баг в stylelint редактируется, я хочу поделиться новостью о том, что я буду проводить воркшоп на любимой конференции HolyJS 2021 Piter про эффективную настройку CI/CD для JavaScript проектов - https://holyjs-piter.ru/2021/spb/talks/7bbwiyuoqpbqhlhv4hmsl1/

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

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

Вносим багу при помощи stylelint
Я начал миграцию с scss-lint на stylelint, но не прочитал документацию. Типично для программиста. Думал, что опция кеширования в stylelint работает аналогично ESLint, но я ошибался. По началу всё выглядело прилично: миграция завершилась, разработчики довольны. Но на прошлой неделе мой коллега, Денис Мишунов, спросил, зачем в процессе миграции подняли вложенность селекторов с 3 до 6.
После вопроса Дениса о вложенности я разобрался, как это вышло. Понизил максимальную вложенность с 6 до 3 и запустил stylelint. Он мне бодро сообщил о ряде ошибок, но это было предсказуемо. Ради дополнительного теста я запустил stylelint ещё раз и удивился пустому выводу. Естественно, я запустил его ещё раз и вывод снова был пустым. Так мы обнаружили проблему с кешированием в stylelint.
Вините во всем кеширование :) Удалив файл кеша .stylelintcache, я вновь получил ожидаемые ошибки. И нашёл проблему.

stylelint и его кеширование
Опция кеширование в stylelint не работает аналогично опции в ESLint. Кеширование просто включает в себя проверку размера файла, время последнего изменения и хеш конфигурации stylelint. Кеширование не включает в себя сохранение результатов. Кеширование не предполагает сохранение результатов. Поэтому при повторном запуске stylelint вы не получите найденные ранее ошибки и предупреждения. Нашли багу или странное поведение? Надо сообщить разработчикам. В моём случае сообщение о странном поведении кто-то уже создал: https://github.com/stylelint/stylelint/issues/4314

shorts: Как сломать GitLab и другие зависимые проекты?

На слуху еще история с автором NPM пакета left-pad, как тут возникла история с гемом mimemagic - https://github.com/minad/mimemagic/issues/97
Автор гема нарушил лицензию GPL популярного пакета в Linux shared-mime-info путем распространения гема под лицензией MIT.
Быстро поменять лицензию не получилось, что в результате повлекло за собой большое количество проблем с Rails и приложениями на Rails из-за того, чтобы сменить лицензии недостаточно, а нужно опубликовать новую версию гема, но можно просто запинить коммит, что мы и сделали как временное решение.

P.S. А еще, автор NPM-пакета stylelint-scss опубликовал новую версию с новым адресом электронной почты (при этом старые версии были опубликованы с использованием почты на свободном уже домене) и команда NPM уже неделю (!) не может сообщить нам, было ли это проверенным изменением. NPM экосистема до сих пор плещется на дне, к сожалению.

Небольшая тишина обусловлена тремя вещами:
- Подготовкой к воркшопу на HolyJS (сегодня!) про использование GitLab CI/CD для JavaScript проектов
- Подготовкой анонса крутой штуки в конце воркшопа
- Бумажной волокитой для одного очень важного дела в GitLab. Эта волокита и отбирает большую часть свободного времени.
Но два поста (код ревью с человеческим лицом и работа в рамках спринта) уже находятся на редактуре и один из них будет опубликован на этой неделе.

А вот и упомянутый анонс-бонус :)

Первый совместный мастер-класс на платформе JavaScript.ninja!

Всегда хотели освоить CI/CD но не знали с чего начать? Или пробовали но уперлись в банальный "копипаст" заклинаний? Нам это более чем знакомо

Я и @vitallium сделали мастер-класс именно для JavaScript-инженеров желающих научиться CI/CD!

Как всегда до 1 мая хорошие скидки (а при покупке двух мастер-классов - прямо неприлично хорошие!)
https://javascript.ninja/workshops/ci-cd

На этой неделе мы обновили наш список поддерживаемых браузеров:
- chrome >= 84
- edge >= 84
- firefox >= 78
- safari >= 13.0.4

Это позволило уменьшить JS bundle на ~120Кб. Не такое уж и большое число, но самое главное еще впереди. Мы очень близки к тому, чтобы удалить Babel из инструментов и перестать его использовать. Останавливает нас любовь наших инженеров к оператору Optional chaining, который, кстати, недоступен в шаблонах Vue.js, так как шаблоны не проходят сквозь Babel, а проходят через buble.

👋 Хотите ли вы Ruby 3.0 в продакшене? У меня, возможно, есть ответы на ваши вопросы о переезде на Ruby 3.0. Буду выступать на RubyRussia 24-25 сентября. https://rubyrussia.club/

Про карму

У GitLab больше нет кармы, а вернее наконец-то мигрировали остатки тестов с Karma на Jest.
Миграция далась не так просто из-за того, что эти остатки были написаны исключительно под
реализации Web API в браузерах, например, getBoundingClientRect. В Karma все работает отлично, а вот в Jest (с JSDOM) такие API обычно или не реализованы или возвращают нулевые значения.
Так или иначе, мы довольны тем, что удалось удалить Karma, но, и это исключительно мое мнение, миграция была бы завершена гораздо быстрее, если бы разработчики не писали
интеграционные или компонентные тесты в unit тестах.

Тишина была тут. Возвращаемся.

Несколько месяцев не было сообщений в канале по двум важным причинам:
- GitLab вышел на IPO 🎉
- Я не пишу фронт больше :)

IPO прошло без каких-либо проблем, но пришлось пообщаться с нашими юристами на тему того, что можно писать в канале и как нужно, но это стандартная практика для публичных компаний. В канале я не пишу ничего запрещенного.
А вот вторая причина куда серьезнее сказалась на возможности писать посты. С июля текущего года я нахожусь в команде InfraDev, которая отвечает за инфраструктуру нашего приложения. Fulfillment как «скрытый» stage в GitLab имеет свое собственное приложение — https://customers.gitlab.com. Это портал для покупателей, где можно покупать, продлевать, отменять подписки, покупать дополнительные CI минуты и прочее. В связи с тем, что не только сам портал является legacy приложением, но и инфраструктура, где он работает, было принято решение по модернизации инфраструктуры и сформирована команда InfraDev с 4 инженерами, куда попал и я.
В наши задачи входит создание новой инфраструктуры и перенос приложения на нее. Изначально, всю работу планировали на 2 спринта, но наша команда инфраструктуры сильно занята GitLab.com, в итоге, вся работа растянулась больше 2 спринтов и идет до сих пор. К тому же, есть нюансы с юридической точки зрения.
Наш портал не хранит платежные данные, но эти данные все равно попадают под различные законы, и просто добавить новое приложение в нашу инфраструктуру нельзя. Получилось так, что приложение будет работать немного обособленно: облако такое же — GCP, а вот остальное будет свое: k8s кластер, мониторинг, уведомление и прочие плюшки. Спасибо нашей команде Infrastructure за то, что все runbooks и инструменты для разворачивания хорошо документированы, а то процесс затянулся бы еще дольше, до следующего года.
В итоге, процесс переноса все еще идет, фронт я пишу крайне редко, но это временно. Новости по фронту конечно же есть и напишу о них позже

Про 2022

Пока многие в компании ушли на каникулы, можно спокойно рассказать, что происходит у нас на Frontend и планы на будущее.
Самое главное - переезд на Vue 3. Работа в этом направлении уже ведется полным ходом:
- Илья Климов творит чудеса с vue-test-utils и bootstrap-vue. Илья стал мейнтейнером boostrap-vue и опубликовал роадмап - https://github.com/bootstrap-vue/bootstrap-vue/issues/6872.
- Наташа Теплухина делает магию с Apollo и GraphQL, чтобы мигрировать на Apollo 3.
- Ecosystem Foundations продвигает уход от bootstrap-vue в сторону GitLab UI Kit.
Помимо переезда на Vue 3, идет трансформация интерфейса GitLab на Vue из HAML шаблонов.
А еще были обновлены иконки! Они теперь безумно классные.
Выглядит все замечательно и вкусно, но без ложки дегтя не обойтись. Использование новых технологий не избавляет от технического долга, которого у нас огромное количество. В стремлении обновить все, мы забываем, что у нас есть злачные места, на которые все забили:
- Тесты. Часть тестов до сих пор использует устаревшие методы тестирования.
- Зоопарк в стейт менеджменте. На текущий момент у нас 3 инструмента для стейта, которые любят миксовать между собой.
- Различные подходы к реализации стандартного функционала. CRUD таблица, например, может быть реализована как угодно автору.
- Слабая отдача в поддержке и актуализации Frontend гайда.
- Производительность. Тут просто без комментариев.
Отрицательные моменты есть и будет всегда, самое важное тут - найти баланс между их устранением и актуализацией текущей кодовой базы. В итоге, мы будем пытаться сесть на два стула сразу в следующем году.

Про Jest 27

Уже давно занимаюсь миграцией в GitLab на Jest 27 и идет процесс туго. Постоянные проблемы с модулями, зависимостями и новым раннером circus.
В процессе возникал вопрос, а почему так происходит? А вчера, думаю, нашел ответ на вопрос, оказывается не только главный мейнтейнер Simen Bekkhus не работает над Jest уже давно, а никто в Facebook (Meta) не работает над ним.
На реддите один из пользователей выдал инсайд, что Meta заплатила ему за то, чтобы он не тратил свое время на Open Source. Верить или нет этому инсайду - личное дело каждого. Моя ошибка, я читал по диагонали. Meta предложили ему компенсацию, а Simen отказался по личным причинам. На реддите есть удаленный комментарий. Но это не отменяет факта, а стоит ли продолжать миграцию на Jest 27 в GitLab?

Про Apollo 2 => 3

Свершилось! Долгая миграция с Apollo версии 2 на версию 3 наконец-то завершена. Миграция длилась почти год и была очень насыщенной, приходилось много раз откатывать промежуточные изменения из-за разных проблем. В течение года мы выкатывали: ESLint правила для миграции, счетчик запросов в процессе для e2e тестов, корректные типа политик и огромные пачки фиксов для миграции в unit тестах. Как и для любой крупной фичи, у этой тоже есть DRI, этого инженера GitLab вы прекрасно знаете - Наталия Теплухина 🎉

Про Jest 27.

Наконец-то! Jest 27 прилетел в главную ветку. Переезд был довольно сложный и часть улучшений пришлось оставить на потом:
- переезд на новый раннер jest-circus
- использование новых fake timers
При включение любой из опций много тестов падало и починить все сразу вылилось бы в раздутый merge request. Решили реализовывать постепенно.
Из неприятного: в процессе переезда выяснилась одна неудобная проблема: из-за рефакторинга таймеров в Jest между хуками beforeEach и it успевает пройти один или несколько тиков и тесты, где мы проверяем шаблон в стадии загрузки, теперь падают. Например, тест ниже проходит в Jest 26, но в Jest 27 падает:

beforeEach(() => {
  createComponent();
});

it('renders the loading icon', () => {
  expect(findLoadingIcon().isVisible()).toBe(true);
});

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

Радуют две вещи: во время переезда были удалены "плохие" тесты и наш CI стал чуточку быстрее, но будет еще быстрее после перехода на Jest 28 и новый раннер.