Бандлинг зависимостей в пакетах

На выходных возился с vitest’ом, искал узкие места и обратил внимание на то, что они бандлят свои зависимости и в таком виде публикуют пакет.

Вот так выглядит строка в стек-трейсе:

(anonymous vendor-index.1ca68bd5.js:50) (file:///home/jenkins/agent/workspace/selene/node_modules/vitest/dist/vendor-index.1ca68bd5.js:50:17)

Ну, понятно, что какая-то зависимость. Открываю файл — никаких комментариев что это за модуль, благо хотя бы не минифицирован. Посмотрел что эскпортируется (в моём случае export { createBirpc as c }), пошёл в репозиторий витеста искать этот самый createBirpc и нашёл строчку:

import { createBirpc } from 'birpc'

Мда. Честно, я вот совсем не понимаю какую проблему такой бандлинг решает. Кажется, вся эта обсессия с уменьшением размеров нод-модулей зашла слишком далеко.

Ну и если уж и бандлить, то и сорсмапы поставлять, но даже так их придётся явно включать через --enable-source-maps. В общем, бесит. Какая-то странная экономия байтиков через ухудшение DX (developer experience).

Sorry Cypress Not Sorry

Любите ли вы JS-драмы так же, как их люблю я?

Есть такая штука для написания E2E тестов в браузере — cypress. Существует вот уже 9 лет. Я знаком с ним очень поверхностно, но в целом мои впечатления от него положительные — с тестированием браузеров всегда всё было очень плохо и непонятно (да, селениум, я про тебя), а тут тебе всё просто, понятно и на JS.

Но сам сайпрес — это просто тест-раннер. А помимо запуска тестов вам захочется ещё смотреть отчёты, реплеи упавших тестов, чтоб понять что случилось, параллелить запуск тестов, чтобы они не занимали вечность и т.д. Всё это делается через Cypress Cloud — отдельный платный продукт.

Как известно, платить хочется далеко не всегда. Так подумал и Андрейс Голдис (agoldis) и практически единолично написал sorry-cypress — опенсорсную альтернативу, которую можно развернуть в том числе и у себя. А вместе с этим он запустил currents.dev — sorry-cypress на стероидах, прямого конкурента Cypress Cloud. У них практически полный паритет по фичам, местами currents умеет чуть больше и имеет более гибкий и дешевый прайсинг.

Currents, как и sorry-cypress, существует вот уже пару лет. Но 25 сентября в блоге сайпреса вышел пост Changes in defense of Cypress Intellectual Property. Написан он достаточно странно: что-то в духе «мы ограничиваем работу сайпреса в некоторых сторонних продуктах и сервисах». Ограничения ввелись начиная с 13 версии сайпреса.

Андрей написал ответный пост Cypress.io Blocking of Sorry Cypress and Currents, в котором разобрал как именно сайпрес детектит использование в «нежелательных» окружениях.

Из-за публичной критики сайперсу пришлось объяснять свои действия в отдельном посте Why Cypress decided to block Currents.dev and Sorry Cypress. И, как видите, явно обозначить что же всё таки означало «defense of Intellectual Property» и явно перечислить причины блокировки: кибер-сквотинг, использование бренда и т.д.

Но помимо объяснения, сайпрес забекпортили блокировку в 12 версию сайпреса и, тем самым, сломали тесты всем пользователям sorry-cypress.


У меня по поводу этого всего есть следующие мысли:
1. Имя sorry-cypress действительно не очень удачное — как минимум это просто некрасиво.
2. С другой стороны пакет cypress имеет MIT лицензию, а Cypress — это отдельная компания.
3. Судя по всему Андрей действительно смог поставить Cypress в уязвимое положение, иначе бы этой истории не было. Возможно, у сайпреса действительно не самый лучший прайсинг и им стоит поработать в этом направлении.
4. В целом, запрет использовать новые версии сайперса в «нежелательных» окружениях — это нормально. Но бэкпортить ограничения в старые версии, которыми пользуются юзеры — очень грязный трюк. Это может сильно повлиять на репутацию и заставить пользователей мигрировать на другие инструменты (тот же Playwright).
5. Думаю, что у Cypress как компании нет никаких легальных рычагов давления. По идее они могли бы пойти в суд, но видимо понимают, что ничего не получится.
6. Оценить какое количество юзеров это задело, кажется, невозможно, но у докер-образа agoldis/sorry-cypress-director 6.6 миллионов пулов только с докерхаба (а многие используют кеширующие прокси для таких целей).

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

https://aviasales.ru/about/vacancies/3524837

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

https://xn--r1a.website/valya_posts_links/5

Prettier in Rust challenge

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

А 10 дней назад Christopher Chedeau более известный как Vjeux и автор Prettier анонсировал челендж — тот кто портирует prettier на rust, получит $10 000. К нему присоединился Guillermo Rauch (CEO Vercel) — итого $20 000. Основной критерий — 95% тестов преттиера должны выполняться. Так же там по мелочи ($2.5к) дают за компиляцию в WASM и поддежку NAPI-RS.

И, кажется, у этого челенджа есть победитель — Biome (ex Rome, я много писал о них, можете поискать по каналу).

В Biome очень хорошо консолидировались и за полторы недели достигли цели. У них получилось это сделать так быстро, т.к. форматтер и до этого покрывал большое количество тестов, что-то около 92%.

Так же в челендже была замечена команда Oxc — за неделю они успели покрыть 21% кейсов. А создатель SWC решил, что у него нет на это времени.

В целом, я рад за биом — им деньги нужны как никогда. Но я точно не могу назвать преттиер медленным. И у меня возникает вопрос — а этот челендж действительно имеет смысл? Так же думает и Isaac Schlueter, создатель npm и подмечает, что самая быстрый способ — не совершать работу в принципе, кешировать и параллелизировать.

Кстати, у преттиера уже есть кеширование:

yarn prettier --cache --cache-strategy content

Чего преттиеру не хватает, так это параллельности.

Кристофер, как затейник всего челенджа, признаётся, что одна из идей — найти героя, который найдет узкие места в самом преттиере.

К примеру, преттиер резолвит .editorconfig для каждого файла. Кеширование резовла конфига сокращает резолв с 12 секунд до 13 милисекунд при форматировании 20 000 файлов. Ну и вот ишью об этом.

В целом, история с челенджем странная. Мне кажется правильней было бы объявить баунти для самого преттиера… Ну и посмотрим на сколько биом будет быстрее, если, конечно, будет.

Ну и тем временем biome пытаются интегрировать в репозиторий ноды, но консенсуса пока не наблюдается. Один из жирных минусов — 100мб для каждой версии биома в репозитории.

Ну а ESLint не остался в стороне. Anthony Fu, член команды Vue, решил поддерживать правила форматирования и вынес их в проект ESLint Stylistic. Что-что, а это я точно считаю неправильным решением — нам нужно меньше форматеров, а не больше…

Object.groupBy() и Map.groupBy() достигли stage 4

Новость, как и методы, прекрасная! Боюсь сосчитать сколько раз мне приходилось писать что-то подобное.

Пример использования:

const array = [1, 2, 3, 4, 5];

// `Object.groupBy` groups items by arbitrary key.
// In this case, we're grouping by even/odd keys
Object.groupBy(array, (num, index) => {
  return num % 2 === 0 ? 'even': 'odd';
});
// =>  { odd: [1, 3, 5], even: [2, 4] }

// `Map.groupBy` returns items in a Map, and is useful for grouping
// using an object key.
const odd  = { odd: true };
const even = { even: true };
Map.groupBy(array, (num, index) => {
  return num % 2 === 0 ? even: odd;
});
// =>  Map { {odd: true}: [1, 3, 5], {even: true}: [2, 4] }

VSCode 1.85: Floating windows

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

Ну что ж, можно поздравить этих самых владельцев нескольких мониторов! Мне же эта штука показалась интересной по двум причинам.

1. Судя по всему реализовать это было не очень просто либо это было совсем неприоритетной задачей.

2. Я пользуюсь внешним терминалом (iTerm), который показывается на любом воркспейсе на пол экрана по хоткею. Но работая с вскодом удобней использовать встроенный, т.к. в нём работает парсинг и всякие ошибки удобно смотреть в панельке «Problems» и перемещаться между ними. Уже какое-то время терминал можно перенести в поле редактора (ну там где файлики открытые) через команду «Move terminal into Editor Area», а теперь его можно будет и вынести в отдельное окно. Far from perfect, но мне определённо нравится куда всё это движется. Может быть когда-нибудь и перепридумаю свой воркфлоу. Хотя я, конечно, хотел бы иметь возможность как-то связывать внешний терминал с вскодом…

На текущий момент этой фиче посвящено 37 ишью, что как бы намекает, что она работает неидеально и будет дорабатываться. Отдельно отмечу возможность вытаскивать панели и вьюшки, а не только редактор: Aux window: allow detaching views and panels.

VSCode 1.85: Multi-file diff editor

Есть одна вещь, которую я ненавижу в ГитХабе — страничка с дифом у пул-реквестов. А ненавижу я её, потому что пользоваться ей невозможно. Я не понимаю, как ключевая часть продукта может быть сделана так плохо. Я понимаю, что это сложная задача, даже Илья Климов пришёл в твиттер со словами «Как человек пытающийся сделать это в гитлабе - это очень сложно :)». Но, однако, к ГитЛабу у меня никаких претензий нет. Ну т.е. можно ли сделать лучше? Ну, да. Но у них хотя бы список файлов не грузится минуту. Обычно к таким постам приходят люди со словами «а ты не пробовал делать пул-реквесты поменьше???». Это, кстати, для меня прям показатель неопытности: не все пул-реквесты реально разбить на части, особенно какие-то миграции на другие подходы и библиотеки. За 3 года в Авиасейлс у меня было множество ПРов на 5000 строк, но дифф сводится к 5 строкам в 1000 файлах. Самое смешное, что после какого-то количества файлов ГитХаб просто не показывает дифф, и приходится тыкать кнопочку «Show diff» на каждом файле. Треш!

Так вот, я какое-то время ходил вокруг да около, пытаясь оптимизировать как-то процесс ревью хотя бы для себя: правило хорошего тона «сначала посмотри сам, потом отдавай на ревью».

1 вариант был открывать дифф в браузере, нужно просто добавить .diff к пру:
github.com/nodejs/node/pull/51124.diff
Но смотреть такое невозможно — просто простыня текста

В качестве 2-го варианта я попробовал официальный CLI ГитХаба:
gh pr diff — отдаёт тот же самый дифф, что и первый способ, но уже с подстветкой. Иногда я запихивал этот дифф в diff2html. Так же я пытался прикрутить delta, чтобы не покидать консоли (это всё таки работает быстрее, чем браузер), но мне не хватило усидчивости его приготовить.
В общем, последний год я просто вызывал gh pr diff и листал вывод. Не могу сказать, что меня устраивал это способ, но работало точно лучше ГитХаба и позволяло оценить нет ли лишних изменений в ПРах.

И вот в VS Code 1.85 появилась экспериментальная фича multi-file diff editor. Это, в общем-то, тот же дифф, что всегда был в вскоде, только в виде простыни из файлов. И знаете, оно работает! Не идеально, но работает!

Я открывал пул-реквест в ноду выше: github.dev/nodejs/node/pull/51124.
Дифф внушительный 1854 файла —+48,035 −17,659 строк. Да, нужно подождать пока оно прогрузится, но я лучше подожду, чем буду постоянно пользоваться лагающим интерфейсом. Да, это не 60fps и даже не 30, но я скролю в любую позицию и сразу же вижу файл и его дифф. И да, могу прям здесь написать комментарий к любой строке. В общем, я в восторге!

Т.к. фича экспериментальная, то её надо принудительно включить:
"multiDiffEditor.experimental.enabled": true

Такой дифф доступен для локальных и staged изменений, incoming/outgoing изменений при мёрдже и для просмотра пул-реквестов.

Vitest: 9 месяцев спустя

Напомню, мы в Авиасейлс переехали с Jest на Vitest и были (ну, я уж точно) не очень довольны результатом. Прошло 9 месяцев, вышла Vitest 1.0 (а актуальная версия уже и 1.2.1) и мы научились с ним как-то жить.

Во-первых, я оказался прав на счёт шардирования. В синтетических тестах (только vitest в пайплайне, это существенно ускоряет тесты) используя 12 тредов, тесты проходили за ~3 минуты. 4 шарда по 3 треда в каждом (с меньшим количеством тредов тесты начинали зависать) мы укладываемся в ~2 минуты. Сайд-эффект шардов — теперь у нас 4 разных отчёта, а не один единый. Неудобно. Команда Vitest открыта к blob репортерам, как в playwright. Их можно склеить после и получить единый отчёт. Осталось написать ишью и реализовать, хех.
Касательно перформанса тредов вот моё ишью — The performance of threads doesn't scale much after 8 threads.

Во-вторых, нам удалось стабилизировать тесты и избавиться от залипаний и случайных падений. С тех пор мы обновились до node v18.19.0 и vitest v1.1.3, удалили любые исключения из poolMatchGlobs и используем threads пул (стандартный и не самый быстрый).

В-третьих, нестабильность витеста породила особенный подход обновлению его самого и ноды. Мы запускаем 100+ пайплайнов по крону, смотрим fail rate и принимаем решение об обновлении или включении каких-то опций. Как я сказал выше, на v1.1.3 нам удалось добиться 100% стабильности, но вот уже с v1.2.1 (latest) один из тестов начинает отваливаться в трети случаев.

В-четвёртых, я был не особо прав, когда сравнивал типы пулов. С тех пор в витесте появился пул vmThreads, который полностью копирует подход из джеста. Он действительно быстрее (в нашем случае срезает ~30 секунд), но менее стабильный и течёт по памяти (как и джест).

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

Vitest: шардирование

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

Вот так мы запускали витест до:

VITEST_MIN_THREADS=12 VITEST_MAX_THREADS=12 yarn vitest --reporter=html --reporter=html --outputFile.html=./vitest-reports/01/index.html

А вот так запускаем теперь (команды запускаются параллельно):

VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=1/4 --reporter=html --outputFile.html=./vitest-reports/01/index.html

VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=2/4 --reporter=html --outputFile.html=./vitest-reports/02/index.html

VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=3/4 --reporter=html --outputFile.html=./vitest-reports/03/index.html

VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=4/4 --reporter=html --outputFile.html=./vitest-reports/04/index.html

Обратите внимание, что каждый отчёт живёт в отдельной директории и пока что нет способа их склеить.

https://vitest.dev/guide/cli.html#shard

git rerere

Как говорится, чем больше ты знаешь, тем меньше ты знаешь. Сегодня я узнал, что в git есть фича запоминать разрешённые при мердже или ребейзе конфликты.

Например, если вы работаете в какой-то «гигаветке» (долго делаете большую недробимую фичу), постоянно подливая из других веток изменения и разрешая одни и те же мерж-конфликты, то с включённой в конфиге опцией rerere (reuse recorded resolution) вы можете разрешить конфликт всего один раз, а затем git, если увидит, что в файле с таким-то именем уже была ситуация, что у нас такая-то строчка, а снаружи пришла такая-то строчка, то разработчик решал конфликт вот так. И, собственно, не будет спрашивать ещё раз, а решит, как вы решили в первый раз.

git config --global rerere.enabled true

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

https://git-scm.com/book/en/v2/Git-Tools-Rerere

Мне, кстати, кажется это многое говорит о том какой гит "юзер-френдли"...

Temporal

Ну и история! 13 мая 2017 появляется первый коммит Temporal Proposal - нового апи для управления датами, вдохновленный moment и luxon.

Ключевые отличия от Date: продуманная работа с часовыми поясами, иммутабельное апи, работа с интервалами (Duration). Схема ключевых сущностей.

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

Я сам использовал этот полифил в течении года, пока пилил проект на ноде, остался очень доволен! С багами не сталкивался, только сделал ПР с улучшением типов (приятно делать даже небольшой вклад в такие крупные проекты)

Уже в 21 году я считал сам пропосал и полифил к нему самым продуманным и проработанным тулом для работы с датами. И сейчас так считаю, но смущает 200 kB (50 kB gzip), что бы тянуть на фронт. Хотя стоит учитывать, что когда оно появится в браузере вы сможете просто вырезать полифил не меняя сам код, чего не скажешь про остальные либы для дат из NPM.

Но почему это все еще не стандарт?

Ключевая фича нового апи - работа с часовыми поясами, не могла быть реализована из-за недоработки самого стандарта часовых поясов. Ужвал - сотрудник Игалии и основной разработчик Temporal, а так же просто очень крутой чел, внес предложение в стандарт дат всея интернета по расширению формата хранения и передачи времени с возможностью расширять его дополнительной информацией. Например?

По закону на Гаваях время должно быть одно, но все местные живут по другому, кто прав? Это не придуманная ситуация, а реальная проблема с которой столкнулся разработчик у нас в чате. Предложенное расширение стандарта позволяет указать не только часовой пояс, но и конкретный “календарь”, который может иметь свою специфику.

23 октября 2023 предложение апрувнули!

Работа над темпорал продолжается, серьезных блокеров, кажется, больше нет. Текущий статус трекатеся тут: https://github.com/tc39/proposal-temporal/issues/2628

Мне сложно сказать, когда предложение станет стандартом и мы увидем его в браузерах, но вот в V8 реализация Temporal занимает уже больше 2.6% бинарника и вы уже можете использовать его в Deno.

Напоследок, очень порекомендую великолепный доклад Пару календарей назад я был совсем другим Алексея Охрименко, для понимания всей проблематики. А вот доклад конкретно про Temporal: How to Outsmart Time Building Futuristic JavaScript Apps Using Temporal

GitLab copyright strike

4 года назад я работал в Альфа-Банке и был у нас там гитлаб. Хорошая штука: и селфхост, и дифф быстро работает, и CI есть, и регистр пакетов. В общем, не инструмент, а мечта!

Но одна штука меня очень сильно раздражала — перенос строк в логах CI. Особенно сильно бесило это при использовании покрытия кода (coverage) в Jest. Он там рисует достаточно широкую и массивную табличку, и смотреть на всё это в маленьком окошке очень неудобо.

Я немного подумал и за один вечер написал простенькое расширение для браузера: берём лог, делаем сплит по строкам, парсим ANSI, рендерим как виртуальный список. Дешёво и сердито. Контрибьютить в гитлаб мне почему-то тогда не захотелось. Видимо, подумал, что это будет не очень просто.

Спустя год я уволился из Альфы, перестал пользоваться гитлабом и благополучно забыл про экстеншн. Но вот неделю назад мне пришлось вспомнить о нём: на почту пришло сообщение «Unauthorized Use of GitLab Intellectual Property». Меня похвалили за экстеншн (американцы ж без этого не могут, вы знаете), но сказали что я мягко говоря не прав т.к. использую в название «GitLab» и ещё и над логотипом надругался (покрасил в другие цвета). Что ж, справедливо — трейдмарк есть трейдмарк™.

Склонировал репо, попытался установить зависимости и сбилдить — всё сразу же сломалось. Заметка на будущее — сразу коммитить .nvmrc, чтоб потом не вспоминать на какой это версии ноды работало. Переименовал, поменял (я тот ещё дизайнер) лого — моя совесть чиста. Надеюсь ребята из гитлаба так же считают…

А расширение теперь называется gtlb-job-log-viewer, и им даже 500 таких же страдальцев, как я, пользуется.

P.S. Ради интереса посмотрел как гитлаб нынче выглядит. Мож и не нужен мой экстеншн то? Добавили возможность открыть логи во весь экран. Ну, неплохо, но хотелось бы большего…

Начиная с ноды v20 и в браузерах есть встроенный генератор uuid v4
crypto.randomUUID(), доступен глобально.

Это самый частый юзкейс для пакета https://github.com/uuidjs/uuid и если другие версии или валидация не нужна, смело дропайте.

fetch() performance parity

Из скриншота всё должно быть понятно.

Вот такая вот дорога от экспериментальной фичи до самого быстрого http клиента в ноде. Ну и вот само ишью.

У Маттео есть даже стрим об этом — Improving Node.js fetch() by 10% - From flamegraph to implementation!

P.S. Мне лично тяжко смотреть такие долгие стримы, но из них обычно можно подчерпнуть какие-то новые привычки и оптимизации воркфлоу.

И в догонку статью про внутренне устройство undici — HTTP Fundamentals: Understanding Undici and its Working Mechanism