У yarn есть очень удобная команда yarn upgrade-interactive (и флаг --latest, если вы хотите обновиться до последних версий).

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

Обновляйте свои пакеты вовремя, но не забывайте читать changelog-и, чтобы случайно не сломать свой проект 👌🏻

Руслан @iamroose подсказал, что есть ещё более удобная альтернатива — npm-check-updates

Визуально выглядит свежее и есть возможность обновлять специфичные пакеты через regex или флаги:

# upgrade everything except nodemon
ncu \!nodemon
ncu -x nodemon
ncu --reject nodemon

Домен drugoi.codes оказался слишком дорогим для продления, а drugoi.dev вполне по деньгам 😬

Не знаю, давно ли это есть, но только сегодня заметил, что Github Copilot для VS Code умеет показывать сразу несколько вариантов решений задачи и пользователь может выбрать самое правильное решение.

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

Пользуетесь ли вы Error Boundary в React?

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

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

И как раз на глаза попалась хорошая статья, которая объясняет работу Error Boundary и то, как правильно их компоновать + рекомендует достаточно интересный пакет, который всё сделает за вас под капотом, пользуйтесь на здоровье

https://meticulous.ai/blog/react-error-boundaries-complete-guide/

Открыл старый проект для расширения под Chrome и на душе стало немного теплее.

Можно увидеть такие местами архаичные, для текущего времени, вещи, как:

bower — пакетный менеджер для фронтенда (как npm, только полностью для веба)
yeoman — генератор проектов (детям буду рассказывать, что это был Create React App)
gulp — таск-раннер, который заменил в своё время Grunt.
editorconfig — IDE конфиг для единообразия отступов и прочего в файлах проекта.

А вы застали золотые времена этих инструментов?

5 лет назад мы с @talgautb сделали примитивного бота для казахской латиницы (https://github.com/drugoi/telegram-bot-qazlatyn), чтобы можно было быстро перегнать текст/фразы из кириллица в латиницу.

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

Приняты ли у вас в команде какие-то правила по написанию коммитов?

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

Использовал этот подход в основном в своих собственных проектах и выглядело это примерно вот так:

Красиво? Да. Функционально? Ну, не очень.

Затем я пришёл к использованию в боевых проектов Conventional Commits (CC).

Это очень удобное соглашение, которое позволяет избавить ваш репозиторий от коммитов вида fix bug и, как отличный бонус, автоматическая генерация Changelog-а с правильной разметкой и релиз-менеджмент.

Но чтобы это всё работало правильно, нам необходимо либо найти разработчиков со 100% понимаем дела, либо включить линтинг коммитов.

Здесь нам на помощь приходит Commitlint, который с помощью простых pre-commit хуков позволяет валидировать содержимое сообщения коммита и либо пропускать его, либо выдавать ошибку. Он легко настраивается и позволяет очень быстро добавить в свой флоу разработки щепотку магии.

Единственная проблема, с которой я столкнулся — это валидация скоупов.

Скоуп в контексте CC — это место применения изменений, которые были сделаны в коммите. Например: feat(lang): add Kazakh language
В данном примере lang — это скоуп. Нет каких-то строгих правил по тому, что может являться скоупом, вы задаёте его в рамках своей бизнес-логики/фреймворка.
Но что, если наш разработчик напишет: feat(leng): add Kazakh language

С точки зрения commitlint — всё правильно, но с точки зрения Changelog-а и в целом управления скоупами — это что-то новое и в будущем вам будет сложнее искать связанные с одним скоупом коммиты.

Для решения этой проблемы в конфигурации commitlint придумали правило scope-enum которое позволяет перечислить список разрешённых скоупов в проекте. Его можно собрать самому, а можно воспользоваться python скриптом, который написал мой знакомый Галымжан @gazgolderkz — gist.

Скрипт нужно положить в папку с проектом и перед выполнением скрипта нужно выполнить сбор данных из git log с помощью команды — git log --pretty=format:%s | grep -E '^(\w+)\((\w+|\*)\)' > commits.log

В итоге будет создан csv файл, в котором отсортировано будут делать использованные вами скоупы. Осталось их почистить и добавить в конфигурацию commitlint.

Готово, вы — восхитительны, а ваш репозиторий чист и вкусно пахнет.

Сегодня нахожусь на Kolesa Conf.

Сейчас Андрей Минкин рассказывает про свой путь от разработчика до CTO и обратно.

Понравился слайд, на некоторых местах работы сталкивался с таким.

Мы в AlmatyJS объявили CFP, а также сбор тем на lightning доклады (маленькие доклады по 10-15 минут).

Если давно хотели попробовать себя в выступлениях — это отличный шанс!

https://t.me/almaty_js/25

Прошла уже половина октября, но у вас ещё есть возможность поучаствовать в ежегодном мероприятии, которое устраивает Digital Ocean и его партнёры — Hacktoberfest 2022.

По сути, это такой фестиваль поддержки OSS, где основная цель — помочь вам сделать свой первый PR в публичном репозитории. Регистрация по ссылке — https://hacktoberfest.com/

Конечно, заниматься поддержкой и развитием open source нужно круглый год, но благодаря Hacktoberfest сотни разработчиков делают свои первые PR в различные репозитории. Да, некоторые PR оставляют желать лучшего (удалили/добавили пробелы, например), но если вы, читая документацию, нашли ошибку и поправили её — это заслуживает уважения.

Мой список проектов, где можно помочь своим PR:
1. Если вы носитель казахского языка, то рекомендую обратить внимание на date-fns, я могу помочь вам с обновлением.
2. Документация react.js — good first issues

Ну и большой список репозиториев с лейблом hacktoberfest — Github Topics

Открыли продажи на #AlmatyJS

Финальная программа ещё в работе, но будет интересно и весело.

Билеты продаются на Sxodim — https://sxodim.com/almaty/event/mitap-dlya-razrabotchikov-almatyjs

Самая последняя информация в канале — https://t.me/almaty_js

В конце выходных почему-то сломался дефолтный DNS от Digital Ocean для казахстанских доменов из-за чего два моих бота, которые связанны с казахстанскими сайтами (KazNic и сайт Нацбанка) перестали достукиваться до них и падали в ошибку EAI_AGAIN, что говорит о том, что случился таймаут при запросе DNS записей домена.

Быстрым фиксом было проставление IP адресов в /etc/hosts, но это решение мне не нравилось.

Проведя несколько тестов я выяснил, что домены недоступны только с VPS-ок на Digital Ocean и решил, что можно попробовать сменить DNS-ы на самом сервере.

Если у вас стандартный дроплет от Digital Ocean, то это очень легко сделать: vi /etc/netplan/50-cloud-init.yaml

            nameservers:
                addresses:
                - 1.1.1.1
                - 1.0.0.1

Находим секцию с nameservers и меняем адреса на нужные (я выбрал DNS от Cloudflare).

Note: после ребута сервера эти настройки сбросятся, но кто ребутает свой сервер вообще?

После изменения NS записей выходим из vi и применяем параметры: sudo netplan apply

Готово, можно проверить работоспособность, например, через curl yourwebsite.kz

Ускорение сборки TypeScript проектов

Пару дней узнавал у знакомых, как они собирают свои TS проекты и выяснил, что у многих не включена опция incremental.

Если её включить, то TypeScript будет сохранять промежуточную информацию о компиляции в файлик .tsbuildinfo (можно поменять расположение/название файла через параметр `tsBuildInfoFile`) и тем самым уменьшать время компиляции.

Если, вдруг, вы не использовали эту настройку ранее, то поделитесь результатами до/после в комментариях.
Я, обычно, замеряю такие вещи вот так: time tsc