Все глаза разные

Соблюдая https://news.1rj.ru/str/xavescor_code/13 я пришёл к ситуации, когда у меня остались в статусе "outdated" только библиотеки связанные с UI. И основной проблемой оказалось то, что мы понаписали кучу css кода, который непонятно как будет работать в новых версиях библиотеки.

Очевидное решение: давайте всё заскриншотим. Playwright как раз умеет в них. Но, вот тут начинаются грабли.
Я, как и большая часть моих коллег, использую мак для разработки.
* Новость первая. Каждая ОС рендерит страницу по-разному. Даже в одном и том же браузере. Решение? Давай запихнём всё в докер, чтобы везде был линукс.
* Новость вторая. playwright не работает в alpine, поэтому придётся нести или их базовый образ с убунтой. Или самому использовать убунту. Так как у нас Bazel, то нужно собирать базовый образ с нуля для надёжности
* Новость третья. Хромиум не работает на голой убунте. Нужно доставлять ещё 4 библиотеки, чтобы он запустился
* Новость четвёртая. Браузер на одной и той же ОС, но на разных архитектурах рендерят страницу по-разному. У меня мак на ARM, а в CI x86_64. В итоге перевожу сборку образа на linux_amd64 и запускаю в режиме эмуляции
* Новость пятая. Докер под мак на арме просто зависает в режиме эмуляции. Нужно переносить эмуляцию на уровень розетты
* Новость шестая. Плейрайт в 1 из двух запусков просто падает с ошибкой в бинарных либах хромиума. Но если перезапустить, то в 90% всё пройдёт успешно.

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

Очередной state of
https://survey.devographics.com/en-US/survey/state-of-html/2023/

Советую заполнять, так как на подобные вещи реально смотрят

https://news.1rj.ru/str/xavescor_code/27

Я думал, что будет куда меньше

Стадия первая: отрицание

После увиденного меня никак не покидает мысль о том, что мир куда-то повернул не туда с этим ESM. Посмотри сам:
* В TS проектах мы пользуемся ESM-like, но в 99% случаев проект коспилируется в CJS.
* Webpack и Vite позволяют нам импортить что угодно и это отбило необходимоть задумываться "а что происходит при импорте?". CJS, ESM, CSS, картинки? Пиши import и не думай. Бандлер сам всё сделает. Ну или хотя бы попытается.
* У нас нет скрипта миграции с CJS на ESM. Мы должны всё делать руками для конвертации проекта в новый стандарт. А делать там дофига чего надо:
- require синхронный, из-за чего сделать автозамену на динамический импорт попросту невозможно. Нельзя () => require('lib') превратить в () => await import('lib'). Ты получаешь попросту сломанный код.
- module.exports - это объект, а export {} - это кусок синтаксиса. Мы не можем динамику превратить в статику
- module.exports мутабелен. Ты из одной зависимости можешь изменить состояние в другой.
- jest.mock не умеет нормально в ESM. Тут я бы порекомендовал конвертить тесты в Vitest. Там всё ок.
И это только то, что сразу пришло в голову.
Но даже с этим можно было взять стратегию ESLint'a: исправляем то, что можем, об остальном сообщаем. Но и этого нет.

В итоге я прихожу к тому, что sindresorhus сделал всё правильно(https://news.1rj.ru/str/xavescor_code/18), а текущий мир - это помойка, в котором никто не понимает как работают импорты в его проекте. И это прямо неприятно. В итоге мы походу будем всегда жить в мире, где мы пишем не на js/ts, а на Вебпаке, Роллапе или Витесте. Как минимум пока не появится герой, который сможет автоматизировать переход на ESM.

Отношеньки

"Умение работать в команде". Такое требование было практически в каждой вакансии, когда я ориентировался на русскоязычный рынок. Но не соответствовать этому вроде как сложно. Ты же не будешь их игнорить, унижать на встречах, мешать работать? Да, есть люди, которые забиваются в свой угол и пилят фичу по полгода, нигде не отсвечивая, но это исключения. У большинства людей задачи реализуются за дни, максимум за недели. При этом за это время ты или будешь как-то отсвечивать(результатом работы или своими вопросами), или же не работать. Всё просто: эта строка звучит как "нормально делай - нормально будет".

Но что происходит, когда ты выходишь на новую работу? Тут 2 варианта: "всё зашибись" или же "это говно, которое надо переписать с использованием нормальных практик". И вот тут как раз начинается "умение работать в команде".
У меня на текущем проекте:
- нет стейт менеджера(Это в двойне забавнее, потому что я в 2019 писал об этом https://gist.github.com/XaveScor/99431c573b53b8a0c41fb3b5fec522bc)
- нет фиксированного кодстайла. Мы полагаемся на то, что программист сам знает как написать код понятнее
- используются default export, хотя без них жить проще
- нет налаженной документации фич. Часто к разрабам в личку стечатся менеджеры и говорят "поправь быстрее это"

Это всё на бумаге выглядит очень-очень-очень плохо. Но мы имеем поддерживаемый, предсказуемый код. Менеджеры почти всегда нами довольны. У нас в команде нет текучки кадров. И если человек попадает к нам, то он работает года полтора-два как минимум.

И со временем я фразу "Умение работать в команде" начал воспринимать по-другому: команда - это такой же живой организм как и человек. А человек может меняться только в кризисных ситуациях. К примеру: "тебе грозит смерть от одиночества, потому что ты жирдяй". В зоне комфорта же человек меняться никогда не будет.
Точно так же и команда. Все принятые практики в команде работают на достаточном уровне. Да, ты можешь попробовать аргументировать, что текущие практики говно и их надо сменить. Но подобное разобьётся в 99% случаев об "оно работает". И это правда.

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

P.S. логика выше не работает для новых проектов. В них ты можешь разгуляться как тебе хочется.

Тест комментариев

Раз комментарии работают, то вот сам шпаргалка по http кодам, если забываете их. https://http.cat

Не трожь пока работает

Почти всегда эта фраза верна. Не стоит тратить силы на то, что не нужно. Но не всегда.

Недавно я решил форкнуть gulp, так как мне нравится их подход, но не устраивает что проект заброшен уже года 4. И походу ребята перегорели уже тогда, так как проект в v4 не развивался, а пытался создать видимость отсутсвия багов: https://github.com/XaveScor/gulp/issues/10.

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

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

P.S. если вы у себя внезапно всё ещё используете галп почему-то, то можете перейти на https://www.npmjs.com/package/@xavescor/gulp. Я постараюсь не сломать обратную совместимость и развивать проект.

CV

LinkedIn не так давно добавил наконец-то нормальную генерацию резюме из профиля. Наконец-то можно оставить единый источник правды и поудалять все остальные сервисы.

Интересующая кнопка находится в вашем профиле под кнопкой more

Отношеньки pt2

https://news.1rj.ru/str/xavescor_code/30
Учись работать в команде - не трать время на фигню

Предположим что вы установили какие-то правила по написанию кода. К примеру, у нас в команде мы решили что использовать React.useCallback - не очень хорошая идея и мы написали ему замену. Но есть проблема: как донести идею до команды и контролировать её соблюдение? Потому что у людей есть проблема: они забывают. А тратить время на code review каждый раз, чтобы проверять использует ли человек что-то не то - очень сильно напрягает.

Решение простое: ESLint. Если вы установили какое-то правило - оно должно покрываться линтером. Правило сверху, к примеру, можно покрыть кодом, который изображён на скриншотах выше.
Из этого я пришёл к следующему правилу в отношеньках: если вы сумели согласиться на какую-либо практику, то она ОБЯЗАНА покрываться линтером. Да, есть мелкие исключения, но они мелкие. Остальные правила должны быть в линте.
Из этого следует второе правило: при ревью не принимаются притензии по кодстайлу, используемым апишкам и т.п. Потому что если это плохо, то подобный код должен запрещаться линтером.

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

Полезные ссылки:
https://eslint.org/docs/latest/rules/no-restricted-syntax - запрет написания плохого кода
https://eslint.org/docs/latest/rules/no-restricted-imports - запрет импортов
https://astexplorer.net - посмотреть в какой ast превращается ваш код для правил выше

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

Есть пакет https://github.com/amanda-mitchell/suppress-eslint-errors, который расставит eslint-ignore в нужных местах. В итоге у вас будет и CI зелёный, и новый код будет уже правильным и красивым. А старый вы постепенно переработаете в процессе будущих задач.

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

Для воспроизведения достаточно открыть на одной и той же вкладке эдак 50 видео. К примеру, послушать музыку у плейлисте или же полистать шортсы.

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

Да блин! Чувак 4 года ману копил и, как только я решил форкнуть галп для себя, стал пилить gulp@5. Ну что за невезуха?

Из новостей: галп возможно оживёт(нет)

Анналы

Slack, github/gitlab/jira issues популяризировали идею того, что сообщения - это и есть документация к коду. Но почему-то люди с одной стороны поддерживают это, а с другой стороны наплевательски относятся к этому.

Как делать плохо: https://github.com/XaveScor/gulp/blob/master/index.js#L5
Как делать хорошо: https://github.com/XaveScor/gulp/blob/d90d9476e64e5c684f18e832529d7ac472b028a9/index.js#L5

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

Как воспользоваться?
- На странице гитхаба, которую хотите расшарить нажмите `y`(латинская) и у вас в урле будет урл с хешем коммита.
- Для IDE от JetBrains можно поставить крутой плагин https://plugins.jetbrains.com/plugin/8183-gitlink, который позволяет копировать ссылки на кучу сервисов(github, gitlab, bitbucket, etc) прямо из IDE

Как воспользоваться?
- На странице гитхаба, которую хотите расшарить нажмите `y`(латинская) и у вас в урле будет урл с хешем коммита.
- Для IDE от JetBrains можно поставить крутой плагин https://plugins.jetbrains.com/plugin/8183-gitlink, который позволяет копировать ссылки на кучу сервисов(github, gitlab, bitbucket, etc) прямо из IDE
- Для VSCode сорян, не использую, но уверен, что есть аналог.

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