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

Решение простое: каждое утро лично ты выполняй у себя на проекте команду outdated и обновляй любую зависимость. Желательно красную или же deprecated, если у вас такие есть в проекте.
К примеру, за 2 месяца почти ежедневных вмешательств красная часть стала меньше раза в 2. Ещё 3-4 месяца и, надеюсь, что от красного можно будет избавиться совсем.

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

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

А ещё телега требует премиум, если хочешь длинное сообщение накатать. Больше 1024 символов? Ха. Плати

https://codingfantasy.com/games/css-grid-attack/play

Игра, в которой можно изучить как работают css-гриды. А так же там куча других игр, которые посвящены программированию

Логичным вопросом после https://news.1rj.ru/str/xavescor_code/14 будет: а зачем вообще это делать, если всё работает? Нода прекрасно держит обратную совместимость, npm репозиторий иммутабельный. Весь код будет работать в будущем спокойно.

Оно-то так. Но увы, перестанет работать программист. Сейчас поясню:
- Пример первый. egov.kz Электронное правительство Республики Казахстан. Angular@1. Это сверхактивно развивающийся проект, аудитория которого больше 5М пользователей. Но первый ангуляр приводит к тому, что внутреннюю кодовую базу попросту больно поддерживать. Нет ни библиотек, ни программистов на рынке, ни развития тулинга. Я общаюсь с ребятами оттуда и они чуток на стену от боли лезут.
- Пример второй. nextjs.org. Основной фреймворк для реакта. Это активно развивающийся проект с двумя неприятными нюансами. Первый - они спокойно ломают обратную совместимость в патчах(не минорах и тем более не мажорах). Но это фигня, кмк, так как с этим жить можно. Ну, почитаешь issues и найдёшь решение. Страшно другое. На сайте есть документация ТОЛЬКО для последней версии. Отстал на пару мажорных версий? Ну, удачи тебе. Будет весело.
- Пример третий. nestjs.com По сравнению с next - тут чуть получше, есть версионирование доки. Но есть 1 нюанс: перейдите по ссылке на migration guide https://github.com/nestjs/nest/releases/tag/v9.0.0. И тут начнётся веселуха, потому что вы попадёте на migration guide с v9 на v10, а не v8->v9. Справедливости ради, он всё же существует. Но они сломали ссылки.

Все эти 3 примера - это проекты с огроменным финансированием, которые не умеют в примитивные вещи. А если у гигантов не получается соблюдать базовый DX, то что говорить о мелюзге? Там вообще всё плохо будет. По этой причине лучше пытаться держать актуальным проект сейчас, а не пытаться через 5-10 лет обновить это устаревшее поделие. Возможно, его будет проще переписать с нуля.

Не держи внутри

В мире фронтенда нет вопроса более холиварного, чем то как управлять состоянием. Хочу немного подкинуть в него дров:

Любой UI состоит из двух вещей: из состояния и UI-рендера, который это состояние превращает в HTML и CSS.
Причём состояние можно грубо поделить на 2 части: корневое и зависимое. Попробую объяснить разницу на примере:
- корневое: jwt токен, который мы храним в куке
- зависимое: информация о пользователе, которую мы получаем по jwt токену с сервера.
Т.е. корневую часть состояния приложение может получить только от пользователя.

И теперь вопрос: почему бы не попытаться хранить максимум корневого состояния в URL?
Из плюсов:
- Если пользователь А захочет поделиться страницей, то его знакомый увидит страницу в максимально близком состоянии, которое открыто у пользователя А
- Урл един, а значит все стейт менеджеры смотрят в одно место. У нас возникает единый источник правды

К примеру, посмотрите как работает фильтрация товаров в маркетплейсах(к примеру, в Амазоне или Яндекс.Маркете) или в http://typenoscriptlang.org/play. Они все на каждый чих меняют урл и это сверхудобно как для пользователя, так и для разработчика

Но есть минус пока что:
- Нет кроссбраузерного способа подписаться на изменения урла. Пока есть https://developer.mozilla.org/en-US/docs/Web/API/Navigation/navigate_event, который поддерживается только хромом.

Так что увы, но это мечты о будущем, которое случится неизвестно когда. Хотя всегда можно заманкипатчить window.location и навесить туды своих интерестностей. Но об этом как-нибудь в другой раз.

Тут недавно проскочила новость об очередном раскулачивании компании.
https://www.bbc.com/news/business-66790608

TLDR. Гугл за счёт андроида заставлял производителей железок устанавливать свой поиск, а это вредит конкуренции.

Но подобное происходит не только в Штатах. В Европе тоже активно наседают на гугл https://www.reuters.com/technology/eu-courts-wed-ruling-record-44-bln-google-fine-may-set-precedent-2022-09-14/

Если ситуация выгорит, то это создаст такой нехилый прецедент, так как гугл обязывает производителей не только пихать свой поиск на первый экран, а так же предустанавливать Chrome и прочие свои приложения.
В итоге хром и прочие могут пойти лесом как это было с IE и MS в 2012 году https://en.wikipedia.org/wiki/Microsoft_Corp._v._Commission.
И может оказаться так, что основным браузером на телефончиках через лет 5 будет MS Edge, а не хром.

P.S. В 2017 году было 1в1 такое же дело Яндекс против Гугла в РФ, но тогда люди с дерьмом сожрали Яндекс. Интересно, будет ли переобувка?) https://ru.wikipedia.org/wiki/Дело_Google_в_ФАС

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

Но проблема в том, что 99%(оценочное суждение) вопросов выглядят как: "я вот написал код, он должен работать, но не работает". И почему-то люди не умеют обрабатывать такие ситуации.

Поэтому вот вам инструкция, как решать такие проблемы:
1. найдите 100% рабочий по вашему мнению кусок кода, который можно безболезненно удалить из программы
2. Удаляйте его
3. Смотрите результат.
Если программа стала работать как вы ожидаете, то проблема в удалённом вами фрагменте. Постарайтесь вынести этот кусок кода в отдельный модуль и возвращайтесь к пункту 1.
Если программа продолжает работать не так как вы ожидаете, то значит, что непонятка осталась в неудалённом коде. Возвращайтесь к пункту 1 и продолжайте пока не найдёте проблему.

В итоге после этого цикла у вас есть маленький кусочек кода, в котором есть проблема.

Если вы поняли в чём проблема, то супер. Исправляйте её, покрывайте тестами, так как другие люди не хуже и не лучше вас. Помогите им в будущем. Плюс PR станет читать куда проще.
Если вы не понимаете в чём проблема, то выносите этот пример в какую-нибудь песочницу, к примеру, в http://jsfiddle.net и только ПОСЛЕ этого идите в чат за помощью.
Ваши скриншоты огромного полотна редко когда помогают найти проблему. А вот код, с которым можно поиграться и поэкспериментировать - вполне.

Как говорится: формулирование проблемы - это половина решения проблемы.

#база

// 'use strict2'

thx @kriakiku

Код пишут тоже люди

Урок сегодняшнего дня для меня, что любые разрабы либ, даже из крупных компаний типа Microsoft, могут делать дичь.

Я потратил 4 часа, из-за того, что playwright с его проектами не мержит глубоко конфиги в своих же проектах(возможность внутри тестов задать разные конфиги). Только поверхностно. Контринтуитивно ли это? Ну, да. Но так и живём.

Урок №2: если console.log не выводит сообщение, то возможно что не раннер подавляет stdout, а функция с логом просто не вызывается.

Нужно мыслить тупее и не додумывать.

P.S. если кто-нибудь сделает такой PR, то буду благодарен. Потому что поведение ужасное.

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

Соблюдая 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