Эта неделя была настолько скучной, что я думал вообще ничего не писать, но:

- Весёлость в одной из зависимостей свелта:
https://github.com/A11yance/axobject-query/pull/354
Чувак 1 PR'ом затащил 16 СВОИХ зависимостей в рантайм, заменил jest на СВОЙ аналог и заменил стандартную CI джобу на поделку, написанную собой.
И самое весёлое: никто не знает каким образом этот человек получил доступ к репозиторию. Просто добрый человек, который добавил поддержку node 0.4. Очень полезно, правда?)

- Реакт кардинально ломает обратную совместимость, изменив рендеринг некоторых апи с параллельного на последовательный. Что ломает кучу библиотек, которые позволяют вам делать запросы из рендера, так как они опираются на Suspense в своей логике
https://github.com/facebook/react/issues/29898
Но самое печальное, что эта проблема чуток глубже. Аж тянет "почему реакт идёт куда-то не туда pt4".

- Версель начинает монетизироваться, поэтому опенсорс идёт в контратаку. Проект, который позволяет запускать next со всеми верселевскими апихами поверх AWS или просто рантайма ноды.
https://open-next.js.org/

- Так же появились результаты state of js 2023 https://2023.stateofjs.com/en-US. Но мне там вычленить почти нечего

Почему реакт идёт куда-то не туда pt4

Ограничусь просто ссылкой на https://phryneas.de/react-server-components-controversy.

Плюс обращаю внимание на этот абзац.

So, at the beginning of 2023, I started poking the React team, and the maintainers of Apollo Client, TanStack React Query, and Redux got a meeting with the React team. The message was essentially “yeah , you can try to write an implementation now”. So we did.

Но, как уже вам известно, это не остановило авторов реакта от https://github.com/facebook/react/issues/29898

Ну вот и ко мне домой пришёл Rust.

Мы на проекте используем SWC, так как он весьма быстро собирает код. И вот после обновления на последнюю версию оказывается, что наши сорсмапы - не сорсмапы. Как минимум по мнению SWC.

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

typenoscript & vitest

Typenoscript - это одновременно и прекраснейшее что случалось со фронтом, когда ты пишешь бизнес-логику. Есть подсказки. Ошибки ловятся. Всё прекрасно.
Но так получилось, что мне захотелось написать свою библиотеку @signal_components. И тут я столкнулся с ужаснейшей частью: ты не можешь дебажить типы в привычном для нас виде.
А они, в случае написания библиотеки, могут быть весьма сложными.

Что мы делаем, когда нужно продебажить код? Верно: или ставим брейкпоинт, или ставим console.log и смотрим какие там значения у переменных. Но у TS подобное недоступно. Ты не можешь поставить брейкпоинт во время вычисления типа. В итоге, единственный нормальный выход - TDD. Другими словами, пишем тесты на каждый чих.

В итоге типы превращаются в портянку со скриншота. Ну или вот ссылка, если хочется потыкать самостоятельно https://github.com/XaveScor/signal-components/blob/5ef372090a45535fcfc3364d0606cb2e8e43be8b/src/types. Но я пришёл к тому, что это единственный способ одновременно и дебажить типы, и писать их.

И вот тут уже играет vitest. Интеграция всего в единый тестраннер работает удивительно хорошо. У него есть и cjs, и esm, и ts, и проверка типов, и он позволяет писать тесты в одном файле с логикой(https://vitest.dev/guide/in-source.html), и запускать тесты в браузере(https://vitest.dev/guide/browser.html). Да, часть функций находится в активной разработке, но аргументов за неvitest уже почти не остаётся.

llama.ttf

https://github.com/fuglede/llama.ttf

Как вам идея шрифта, в котором запущена нейронка?

Спасибо подобным наркоманам, потому что я теперь знаю, что в шрифтах можно запускать WASM. (Что?)
https://github.com/harfbuzz/harfbuzz/releases/tag/8.0.0

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

https://blog.cloudflare.com/declaring-your-aindependence-block-ai-bots-scrapers-and-crawlers-with-a-single-click

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

Понедельник. Ссылки.

vitest 2.0. Новый мажор лучшего инструментария для тестов.
https://github.com/vitest-dev/vitest/releases/tag/v2.0.0

Новый сборщик на расте номер 1005001. Единственная вещь почему на него можно обратить внимание: он разрабатывается командой vite. А значит потенциально он будет заменой rollup в будущих релизах vite
https://rolldown.rs/about

Ещё одна причина почему нельзя грузить ресурсы с чужих доменов. Если есть возможность - всегда локализуйте зависимости: скрипты, шрифты и т.п.
https://sansec.io/research/polyfill-supply-chain-attack

Очень годный разбор давно опубликованных результатов state of js
https://www.youtube.com/watch?v=1dReRMvwckY

Инструмент для тестирования запросов нормального человека. Не мокайте fetch или xhr, если это можно не делать
https://mswjs.io

У реакта большой дефицит нормальных DnD решений. Возможно, это одно из нормальных
https://www.neodrag.dev

Прошедший скандал с чуваком, который добавлял поддержку ноды 0.4 в свелт, показал прекраснейший проект. Он направлен на то, чтобы заменять зависимости на уровне менеджера зависимостей и не качать устаревшую дичь к вам на машины
https://github.com/SukkaW/nolyfill

Совместимость и технический PR.

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

Возьмём реакт мир: у нас куча библиотек, которые являются "убийцами редакса", "убийцами react-router", "убийцами реакта", но которые предоставляют примерно 0 совместимости с предыдущими решениями. Почему-то авторы либ считают, что пользователи с радостью будут брать и переписывать проект полностью на новое решение, что пользователи сами будут придумывать как дружить старое решение и новое, что нужно лишь придумывать как делать прекрасный новый мир, не задумываясь над старым.


Хорошим примером противоположного подхода является мной обожаемый vitest, на который мы недавно мигрировались буквально за неделю с jest'a. Причём большую часть времени мы занимались тем, чтобы подружить vitest с нашей немного чуждой системой для фронтенд мира(Bazel). Схожее апи с jest'ом на 90-95% позволило не просто переписывать тесты, не включая мозг, а перепоручить этот опыт LLMке, которая сделала почти что всю работу за людей. Достаточно было промта для chatgpt 4o:

Rewrite the typenoscript file from jest to vitest. Also port the noscript to ESM. Give me ONLY the total file content. No explanations!. No markdown. I want to paste your response directly into the file. Do NOT erase types inside the file.
[File]
${content}

И 95% кода было успешно переписано. Да, в некоторых ситуациях были ошибки. Но их легко поправить руками. Но почти вся рутина была автоматизирована.


Другим хорошим примером является preact. Эти ребята сделали почти полную совместимость с реактом, добавив нормальное решение в виде сигналов. Что позволяет взять и максимально постепенно переписывать код на реактивные рельсы. В отличии от solid'a, который паразитирует на реакте, но заставляет полностью переписывать код.

Ещё один хороший концептуально пример: https://github.com/SukkaW/nolyfill. Чувак ничего не изобретает и просто создаёт более эффективные решения на основе существующих апи.

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

ljharb

Ситуация с ljharb продолжает быть веселее и веселее. Это тот чувак, который решил в доку свелта добавить поддержку ноды 0.4.

Вчера я пытался в очередной раз апнуть наш проект до eslint 9 и увидел, что eslint-plugin-import принадлежит как раз этому челобеку. Следовательно, по классике, этот плагин поддерживает eslint 2, node 4 и прочую некрофилию. А так же чувак попросту не добавляет поддержку flat config и eslint 9. И вот история в том, что игнор идёт уже больше года. В итоге появляется eslint-plugin-import-x: https://www.npmjs.com/package/eslint-plugin-import-x, который поддерживает только eslint 8/9, не имеет кучи говнозависимостей и пока поддерживается новым ментейнером.

Другая история происходит прямо сейчас про библиотеку traverse. Как легко догадаться, туда тоже пришёл ljharb. В итоге ша маемо, то маемо. Но благо, благодаря этому появилась библиотека neotraverse: https://www.npmjs.com/package/neotraverse, которая является форком оригинальной, но без всей этой дичи от нашего поциента.

В итоге, если хотите получить популярный проект, то алгоритм чуток прост:
1. Смотришь, в какой очередной утилитарный проект пришел ljharb и навернул секурности
2. Делаешь форк от прошлой версии без зависимостей, обзываешь neo/nano/x-оригинальное имя и публикуешь
3. Профит, благодарные юзеры благодарны на ровном месте, репутация локального спасителя экосистемы

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

Ну и в продолжение. Узнайте заражен ли ваш пакет ljharb'ом https://voldephobia.rschristian.dev

Миграция.

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

И идеальной ситуацией будет схема:
1. депрекейт фичи в миноре версии x
2. варнинг в версиях x+1,...,x+N-1
3. выпиливание фичи в версии x+N

В таком случае у пользователя есть возможность подготовиться к выпиливанию библиотеки максимально плавно. Такой схеме релизов следуют react, pnpm, Bazel, jest и многие другие.

Однако, зачастую бывает такое, что нужно заменить одно решение на другое. Причём изначальное решение используется в 100500 местах в проекте. К примеру: замена React.useCallback на useEvent. Мы проводим сейчас как раз такую миграцию. И тут основная проблема в трёх местах: нужно как-то донести новое правило до всех членов команды; нужно как-то на code review замену API; нужно как-то контролировать прогресс выпиливания, чтобы не оказаться в ситуации, что у нас будет 100500 одновременных миграций.

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

Мы выработали следующее решение этой задачи:
1. Пишем ESLint правило, которое запрещает использовать старое API;
2. Во все места с ESLint ошибками добавляем ignore комменты, которые отключают ESLint ошибку для конкретных строк
3. Добавляем над ignore комментом TODO коммент.
4. В следующий раз когда программист правит файл, то он может выпилить старое API на новое, заодно проверив функциональность логики

Добавить TODO и ignore комменты можно добавить простой командой:

npx suppress-eslint-errors . --extensions=ts,tsx --parser=tsx --rules=no-restricted-syntax   

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

Одни плюсы, правда если только ты можешь написать ESLint правило

пуштумастер

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

- Делать PR и мержить можно всем
- Ментейнерам можно пушить в мастер, чтобы быстро реагировать на инциденты

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

#!/bin/bash

current_branch="$(git branch --show-current)"
if [[ "master" == "$current_branch" ]]; then
      echo "ERROR: local branch $current_branch is protected" 
      exit 1
fi

exit 0

Если шо, сильно не привязывайтесь к гитлабу

https://www.reuters.com/markets/deals/google-backed-software-developer-gitlab-explores-sale-sources-say-2024-07-17/

Блеск и нищета опенсорса

Jest и Vitest - это лидирующие решения для юнит тестирования js/ts кода. Но вокруг них сложилась удивительная и непонятная для меня ситуация.

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

А теперь давайте глянем на наших лидеров:
Что нам нужно от расширения jest/vitest. В 99% случаев нам понадобится написать собственный matcher. Это та штука, которая пишется expect().ВОТ_ТУТ(). И в таком случае начинается веселье:
- У тебя есть только описание того как просто сделать expect.extend
- У тебя описывается как максимально примитивно добавить типы. У Playwright, к примеру, матчеры различаются в зависимости от того что ты передаёшь в expect. У vitest'a все матчеры находятся в единой помойке. Типизация тут помогает минимально.
- У тебя попросту нет доступа из матчеров к конфигу. Соврал, нет НОРМАЛЬНОГО доступа к конфигу.
И эту сиутацию я хочу рассмотреть.

Вот у меня есть задача: написать снепшотилку директорий. Не важно что это такое. Важно то, что мне нужно получать доступ к флагу -u, который в vitest позволяет понять хочет пользователь сравнить снепшоты или же обновить их.
И делается это очень просто: никак. Точнее, никак это не описано в документации. Но зато нам даётся ссылка на jest плагин, который позволяет делать снепшоты: https://vitest.dev/guide/snapshot#image-snapshots. И тут может возникнуть мысль: "Эврика! В jest'e всё можно сделать, а vitest просто перенёс к себе эти решения".
Ну, часть вывода будет верна: Vitest перенёс решения. Но это не решения, а костыли. В jest так же ничего не описывается.

В итоге все кто пишут плагины к jest, тупо завязываются на внутренние апи. К примеру, флаг -u - это простое выражение expect.getState().snapshotState._updateSnapshot === 'all'. И да, _updateSnapshot - это приватное поле. Приватное поле на уровне типов. И даже в 2019 году было issue, чтобы сделать апи нормальным: https://github.com/jestjs/jest/issues/8732
Но, ничего не изменилось.

И это фигня. Часть апи, к примеру, лежит тупо в global: https://github.com/americanexpress/jest-image-snapshot/blob/da49e578c9a02c50aa841d05ac64e9ffd4b725fd/src/index.js#L193
Всё апи jest'a и vitest'a - это набор костылей, которые можно найти только с помощью метода тыка.


Итог: jest плюёт на расширяемость. Vitest занимается тем, что переносит костыли jest'a и так же плюёт на расширяемость. Так и живём.

Понедельник. Ссылки

https://jser.dev/2023-06-19-how-does-usestate-work/
Как работает useState в реакте. Неплохо мне помогло в написании @signal_components. Я пытаюсь в качестве эксперимента затащить сигналы в реакт. А он активно вставляет костыли тем людям, которые хотят избегать ререндеров.

https://9to5google.com/2024/07/18/googl-links/
Гугл закрыл и этот проект

https://news.1rj.ru/str/workbeer/141
Как корректно делать шорткаты в вебе

https://publint.dev
https://arethetypeswrong.github.io/
Линтеры для package.json. Рекомендую почитать правила, которые они там проверяют. Можно узнать интересное о том как резолвятся пакеты.

https://zed.dev/blog/beta
Отличнейший редактор, теперь есть на Linux. У себя на маке я полностью заменил им sublime text. Всем рекомендую в случае, если требуется просто открыть файл и как-то поиграться с ним

https://x.com/lcasdev/status/1810696257137959018?s=46&t=ohIjgaVZLt6vr9X0nBz1jg
Хром, как неожиданно(нет), даёт гуглу эксклюзивные права на многие ваши метрики(CPU, GPU, RAM, etc) на своих сайтах.

https://news.1rj.ru/str/dotrubic/234
Как GPL руинит мир. Никогда не используйте у себя любую из форм GPL

3rd party cookies

https://privacysandbox.com/news/privacy-sandbox-update/
Результат даже стал хуже. Гугл не справилась с выпиливанием наших любимых кук, поэтому хром в будущем БУДЕТ ДАВАТЬ ВЫБОР ПОЛЬЗОВАТЕЛЮ.
Из двух стульев с проблемами гугл решил выбрать оба. Никакой инфы нет, но теперь могу представить как теперь будет весело писать код. Теперь надо учитывать тупо оба случая.

Вот реально, как им в голову такие решения приходят?

bun, внезапно, реально изменил мир.

Сегодня мне понадобилось написать скрипт околосреднего размера на ts. И это так впадлу настраивать на привычном стеке. А с помощью bun - всё просто:

bun run index.ts --watch

и не нужно никакого tsc, ts-node, nodemon и прочей фигни. Оно просто работает.

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

brew install oven-sh/bun/bun

И да, всё вышенарисованное появилось в ноде как раз благодаря бану

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

К примеру, godaddy попросту украл домен моего знакомого @sergeysova, так как он паспортом не вышел.

Я сам лично пользуюсь namecheap.com и покупал reatom.dev именно там. Так как у них простейшая политика: если они не захотят с вами сотрудничать, то они попросту попросят вас увести свои домены от них куда-нибудь.

Автор effector.dev хостит свои домены на name.com и они тоже нормально относятся к своим клиентам.

Если же вы подумаете что-нибудь покупать, то трижды подумайте, чтобы идти на godaddy. Вам может повезти, но, увы, куче людей не повезло.

Понедельник. Ссылки

https://2023.stateofreact.com/en-US
Результаты опроса. Из приятного: redux ненавидит 30% респондентов.
Советую прочитать этот опрос, так как это хороший способ обновить свои знания.
Плюс, из интересного: добавили комментарии. Их тоже советую глянуть.
К примеру, комментарий к useState

Not because i like it. just because it is default

Ещё бы лайки-дизлайки к комментам добавить и будет идеально

https://news.1rj.ru/str/workbeer/151
setTimeout не такой уж и кроссплатформенный. Node работает чуток по-другому, в отличии от браузеров

https://github.com/nodejs/node/pull/53725
Привет bun. Нода пытается в запуск ts файлов.

https://github.com/public-apis/public-apis?tab=readme-ov-file
Список огромного количество открытых апи с разной информацией

Прямо сейчас правительство в РФ решило взяться серьёзно за ютуб и начать его активно ломать.
И так как у меня в подписчиках достаточное количество россиян, то рекомендую ознакомиться с
https://habr.com/ru/articles/831846/
https://habr.com/ru/articles/832678/

Как минимум, чтобы отсрочить необходимость гонять видео через VPN. А так, существует только 1 нормальный способ обхода блокировок: на уровне роутера.

Древняя статья для древнего микротика: https://habr.com/ru/articles/549282/
Но для того чтобы понять принцип тунеллирования трафика по BGP в VPN - будет полезно.